1、优化代码的第一步——单一职责原则
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。它的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。就像秦小波老师在《设计模式之禅》中说的：“这是一个备受争议却又及其重要的原则。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的”。因为单一职责的划分界限并不是总是那么清晰，很多时候都是需要靠个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。 对于计算机技术，通常只单纯地学习理论知识并不能很好地领会其深意，只有自己动手实践，并在实际运用中发现问题、解决问题、思考问题，才能够将知识吸收到自己的脑海中。下面以我的朋友小民的事迹说起。
自从Android系统发布以来，小民就是Android的铁杆粉丝，于是在大学期间一直保持着对Android的关注，并且利用课余时间做些小项目，锻炼自己的实战能力。毕业后，小民如愿地加入了心仪的公司，并且投入到了他热爱的Android应用开发行业中。将爱好、生活、事业融为一体，小民的第一份工作也算是顺风顺水，一切尽在掌握中。 在经历过一周的适应期以及熟悉公司的产品、开发规范之后，小民的开发工作就正式开始了。小民的主管是个工作经验丰富的技术专家，对于小民的工作并不是很满意，尤其小民最薄弱的面向对象设计，而Android开发又是使用Java语言，什么抽象、接口、六大原则、23种设计模式等名词把小民弄得晕头转向。小民自己也察觉到了自己的问题所在，于是，小民的主管决定先让小民做一个小项目来锻炼锻炼这方面的能力。正所谓养兵千日用兵一时，磨刀不误砍柴工，小民的开发之路才刚刚开始。
在经过一番思考之后，主管挑选了使用范围广、难度也适中的ImageLoader（图片加载）作为小民的训练项目。既然要训练小民的面向对象设计，那么就必须考虑到可扩展性、灵活性，而检测这一切是否符合需求的最好途径就是开源。用户不断地提出需求、反馈问题，小民的项目需要不断升级以满足用户需求，并且要保证系统的稳定性、灵活性。在主管跟小民说了这一特殊任务之后，小民第一次感到了压力，“生活不容易呐！”年仅22岁至今未婚的小民发出了如此深刻的感叹！
挑战总是要面对的，何况是从来不服输的小民。主管的要求很简单，要小民实现图片加载，并且要将图片缓存起来。在分析了需求之后，小民一下就放心下来了，“这么简单，原来我还以为很难呢……”小民胸有成足的喃喃自语。在经历了十分钟的编码之后，小民写下了如下代码：
/** * 图片加载类 */public class ImageLoader {// 图片缓存LruCache<String, Bitmap> mImageCache;// 线程池,线程数量为CPU的数量ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());public ImageLoader() {initImageCache();}private void initImageCache() {// 计算可使用的最大内存final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);// 取四分之一的可用内存作为缓存final int cacheSize = maxMemory / 4;mImageCache = new LruCache<String, Bitmap>(cacheSize) {@Overrideprotected int sizeOf(String key, Bitmap bitmap) {return bitmap.getRowBytes() * bitmap.getHeight() / 1024;}};}public void displayImage(final String url, final ImageView imageView) {imageView.setTag(url);mExecutorService.submit(new Runnable() {@Overridepublic void run() {Bitmap bitmap = downloadImage(url);if (bitmap == null) {return;}if (imageView.getTag().equals(url)) {imageView.setImageBitmap(bitmap);}mImageCache.put(url, bitmap);}});}public Bitmap downloadImage(String imageUrl) {Bitmap bitmap = null;try {URL url = newURL(imageUrl);final HttpURLConnection conn =(HttpURLConnection)url.openConnection();bitmap = BitmapFactory.decodeStream(conn.getInputStream());conn.disconnect();} catch (Exception e) {e.printStackTrace();}return bitmap;}}
并且使用git软件进行版本控制，将工程托管到github上，伴随着git push命令的完成，小民的ImageLoader 0.1版本就正式发布了！如此短的时间内就完成了这个任务，而且还是一个开源项目，小民暗暗自喜，幻想着待会儿主管的称赞。
在小民给主管报告了ImageLoader的发布消息的几分钟之后，主管就把小民叫到了会议室。这下小民纳闷了，怎么夸人还需要到会议室。“小民，你的ImageLoader耦合太严重啦！简直就没有设计可言，更不要说扩展性、灵活性了。所有的功能都写在一个类里怎么行呢，这样随着功能的增多，ImageLoader类会越来越大，代码也越来越复杂，图片加载系统就越来越脆弱……”Duang，这简直就是当头棒喝，小民的脑海里已经听不清主管下面说的内容了，只是觉得自己之前没有考虑清楚就匆匆忙忙完成任务，而且把任务想得太简单了。
“你还是把ImageLoader拆分一下，把各个功能独立出来，让它们满足单一职责原则。”主管最后说道。小民是个聪明人，敏锐地捕捉到了单一职责原则这个关键词。用Google搜索了一些优秀资料之后总算是对单一职责原则有了一些认识。于是打算对ImageLoader进行一次重构。这次小民不敢过于草率，也是先画了一幅UML图，如图1-1所示。
图1-1
你不勇敢，没人替你坚强。
