第一章 走向灵活软件之路-----面向对象的六大原则
（单一原则）一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类应该是一组相关性很高的函数、数据的封装。就想秦小波在<设计模式之禅>中说的：“这是一个备受争议却又及其重要的原则。只要你想和别人争执、怄气或者吵架，这个原则屡试不爽的”。因为单一原则的划分界限并不是总是难么清晰，很多时候都是需要靠个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。
对于计算机技术，通常只单纯地学习理论知识并不能很好地领会其深意，只有自己动手实践，并在实际运用中发现问题、解决问题、思考问题，才能够将知识吸收到自己的脑海中。下面以我的朋友小明的事情说起。
自从Android系统发布以来，小明是Android的铁杆粉丝，于是在大学期间一直保持着对Android的关注，并且利用课余时间做一些小项目，锻炼自己的实战能力。毕业后，如愿地加入了心仪的公司，并且投入到了自己热爱的Android开发行业中、将爱好、生活、事业融为一体，小眀的第一份工作也算是顺风顺水，一切尽在掌握中。
在经历过一周的适应期以及熟悉公司产品、开发规范之后，开发工作就正式开始了。小明的主管是一个经验丰富的技术专家，对于小明的工作并不是很满意，尤其是最薄弱的面向对象设计，而Android开发又是使用Java语言，程序中的抽象、接口、六大原则、23中设计模式等名词把小明弄得晕头转向，自己也就查到自己的问题所在。于是主管决定先让小明做一个小项目来锻炼这方面的能力。正所谓养兵千日用兵一时，磨刀不误砍柴工。小明的开发之路刚刚开始。
在经历了一番思考之后，主管挑选了使用范围广、难度也适中的图片加载器（ImageLoader）作为小明的训练项目。既然要训练小明的面向对象设计，那么就必须考虑到扩展性，灵活性，而检测这一切是否符合需求的最好途径就是开源。用户不断地提出需求、反馈问题，小明的项目需要不断升级瞒住用户需求，并且要保证系统的稳定性、灵活性。在主管根小明说了着一特殊任务之后，小明第一次感到了压力。“生活不易啊！”年仅22的小明发出了这样的感叹！
挑战总是要面对的，何况是从来不服输的小明。主管的要求很简单，要实现图片加载，并且要将图片缓存起来。在分析了需求之后，小明一下就放心下来了吗，“这么简单，原来我还是以为很难啦......”小明胸有成竹地喃喃自语到。在经历了10分钟的编码之后，小明写下了如代码。
/**
* Created by ${whq} on 2020/3/27
*/
public class ImageLoader {
// 图片缓存
LruCachelruCache;
ExecutorService executorService =Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
Handler handler =new Handler(Looper.getMainLooper());
public ImageLoader() {
initImageCache();
}
private void initImageCache() {
// 计算可使用的最大内存
final int maxMenory =(int) (Runtime.getRuntime().maxMemory() /1024);
// 取四分之一的可用内存作为缓存
final int cacheSize =maxMenory /4;
lruCache =new LruCache(cacheSize) {
@Override
protected int sizeOf(String key,Bitmap bitmap) {
return bitmap.getRowBytes() *bitmap.getHeight() /1024;
}
};
}
public void dispalyImage(final String url,final ImageView imageView) {
imageView.setTag(url);
executorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap ==null) {
return;
}
if (imageView.getTag().equals(url)) {
updataImageView(imageView,bitmap);
}
lruCache.put(url,bitmap);
}
});
}
private void updataImageView(final ImageView imageView,final Bitmap bitmap) {
handler.post(new Runnable() {
@Override
public void run() {
imageView.setImageBitmap(bitmap);
}
});
}
private Bitmap downloadImage(String imageUrl) {
Bitmap bitmap =null;
try {
URL url =new URL(imageUrl);
final HttpURLConnection connection =(HttpURLConnection) url.openConnection();
bitmap =BitmapFactory.decodeStream(connection.getInputStream());
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return bitmap;
}
}
并且使用Git软件进行版本控制，将工程托管到github上，伴随着git push命名的完成.，ImageLoader0.1版本就正式发布了！如此短的时间内就完成了这个任务，而且还是一个开源项目，小明暗暗自喜，并幻想着待会儿被主管称赞。
在给主管报告了ImageLoader的发布消息的几分钟之后，主管就把小明叫到了会议室。这下小明纳闷了，怎么夸人还需要到会议室。”小明，你的ImageLoader耦合太严重了！简直就没设计可言，更不要说扩展性，灵活性了。所有的功能都写在一个类里怎么行啦，这样随着功能的增多，ImageLoader类会越来越大，代码页越来越复杂，图片加载系统越来越脆弱......“这简直就是当头棒喝，小明的脑海里已经听不清楚下面说的内容了，只是觉得自己之前没有考虑清楚就匆忙完成任务，而且把任务想的太简单了。
”你还是把ImageLoader拆分一下，把各个功能独立出来，让他们瞒住单一职责原则。“主管最后说道。小明是个聪明人，敏锐的捕捉到了单一职责原则这个关键词，他用Google搜索了一些资料之后，总算对单一原则有了一些认识，于是打算对ImageLoader进行一次重构。这次小明不敢草率，也是先画了一幅UML图，如图1-1所示：
ImageLoader代码修改如下：
/**
* Created by ${whq} on 2020/3/27
*/
public class ImageLoaderNew {
ImageCache imageCache =new ImageCache();
ExecutorService executorService =Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
Handler handler =new Handler(Looper.getMainLooper());
private void updataImage(final ImageView imageView,final Bitmap bitmap) {
handler.post(new Runnable() {
@Override
public void run() {
imageView.setImageBitmap(bitmap);
}
});
}
public void dispalyImage(final String url,final ImageView imageView) {
imageView.setTag(url);
executorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap ==null) {
return;
}
if (imageView.getTag().equals(url)) {
updataImage(imageView,bitmap);
}
imageCache.put(url,bitmap);
}
});
}
private Bitmap downloadImage(String imageUrl) {
Bitmap bitmap =null;
try {
URL url =new URL(imageUrl);
final HttpURLConnection connection =(HttpURLConnection) url.openConnection();
bitmap =BitmapFactory.decodeStream(connection.getInputStream());
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return bitmap;
}
}
/**
* Created by ${whq} on 2020/3/27
*/
public class ImageCache {
LruCachebitmapLruCache;
public ImageCache() {
initImageCache();
}
private void initImageCache() {
final int maxMemory =(int) (Runtime.getRuntime().maxMemory() /1024);
final int cacheSize =maxMemory /4;
bitmapLruCache =new LruCache(cacheSize) {
@Override
protected int sizeOf(String key,Bitmap value) {
return value.getRowBytes() *value.getHeight() /1024;
}
};
}
public void put(String url,Bitmap bitmap) {
bitmapLruCache.put(url,bitmap);
}
public Bitmap get(String url) {
return bitmapLruCache.get(url);
}
}
如图1-1和上述代码所示，小明将ImageLoader一拆为二，ImageLoader只负责图片的加载逻辑，而ImageCache只负责图片缓存的逻辑，这样ImageLoader的代码量变少了，职责也清晰了；当与缓存相关的逻辑需要改变时，不需要修改ImageLoader类，而图片加载的逻辑需要修改时也不会影响到图片缓存逻辑。主管在审核了第一次重构之后，对工作给予表扬，大致意思是结构变得清晰很多，但是可扩展还是比较欠缺。虽然没有得到主管的完全肯定，但也颇有进度，再考虑到自己确实有所收获，原本沮丧的心里也略微地好转了起来。
从上述的例子中我们能够体会到，单一职责所表达出的用意就是”单一“二字。正如上文所说，如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要更具个人经验、具体的业务逻辑而定。但是，它也有一些基本的指导原则，例如，两个完全不一样的功能就应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断地审视自己的代码，根据具体的业务、功能对类进行相对应拆分，这是程序员优化代码迈出的第一步。
