优化代码的第一步——单一职责原则
单一职责原则的英文名称是Single Responsibility Principle，缩写是SRP。SRP的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。就像秦小波老师在《设计模式之禅》中说的：“这是一个备受争议却又及其重要的原则。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的”。因为单一职责的划分界限并不是总是那么清晰，很多时候都是需要靠个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。
对于计算机技术，通常只单纯地学习理论知识并不能很好地领会其深意，只有自己动手实践，并在实际运用中发现问题、解决问题、思考问题，才能够将知识吸收到自己的脑海中。下面以我的朋友小民的事情说起。
自从Android系统发布以来，小民就是Android的铁杆粉丝，于是在大学期间一直保持着对Android的关注，并且利用课余时间做些小项目，锻炼自己的实战能力。毕业后，如愿地加入了心仪的公司，并且投入到了自己热爱的Android应用开发行业中。将爱好、生活、事业融为一体，小民的第一份工作也算是顺风顺水，一切尽在掌握中。
在经历过一周的适应期以及熟悉公司的产品、开发规范之后，开发工作就正式开始了。小民的主管是个工作经验丰富的技术专家，对于小民的工作并不是很满意，尤其是最薄弱的面向对象设计，而Android开发又是使用Java语言，程序中的抽象、接口、六大原则、23 种设计模式等名词把小民弄得晕头转向，自己也察觉到了自己的问题所在。于是，主管决定先让小民做一个小项目来锻炼这方面的能力。正所谓养兵千日用兵一时，磨刀不误砍柴工。小民的开发之路才刚刚开始。
在经过一番思考之后，主管挑选了使用范围广、难度也适中的图片加载器（ImageLoader）作为小民的训练项目。既然要训练小民的面向对象设计，那么就必须考虑到可扩展性、灵活性，而检测这一切是否符合需求的最好途径就是开源。用户不断地提出需求、反馈问题，小民的项目需要不断升级以满足用户需求，并且要保证系统的稳定性、灵活性。在主管跟小民说了这一特殊任务之后，小民第一次感到了压力。“生活不容易啊！”年仅 22 岁的小民发出了这样的感叹！
挑战总是要面对的，何况是从来不服输的小民。主管的要求很简单，要实现图片加载，并且要将图片缓存起来。在分析了需求之后，小民一下就放心下来了，“这么简单，原来我还以为很难呢……”小民胸有成足地喃喃自语。在经历了 10 分钟的编码之后，小民写下了如下代码。
/** * 图片加载类 */public class ImageLoader { // 图片缓存 LruCache<String, Bitmap> mImageCache; // 线程池,线程数量为CPU的数量 ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime. getRuntime().availableProcessors()); // UI Handler Handler mUiHandler = new Handler(Looper.getMainLooper()); 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) { @Override protected 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() { @Override public void run() { Bitmap bitmap = downloadImage(url); if (bitmap == null) { return; } if (imageView.getTag().equals(url)) { updateImageView(imageView, bitmap); } mImageCache.put(url, bitmap); } }); } private void updateImageView(final ImageView imageView, final Bitmap bmp) { mUiHandler.post(new Runnable() { @Override public void run() { imageView.setImageBitmap(bmp); } }); } public Bitmap downloadImage(String imageUrl) { Bitmap bitmap = null; try { URL url = new URL(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类会越来越大，代码也越来越复杂，图片加载系统就越来越脆弱……”这简直就是当头棒喝，小民的脑海里已经听不清主管下面说的内容了，只是觉得自己之前没有考虑清楚就匆匆忙忙完成任务，而且把任务想得太简单了。
“你还是把ImageLoader拆分一下，把各个功能独立出来，让它们满足单一职责原则。”主管最后说道。小民是个聪明人，敏锐地捕捉到了单一职责原则这个关键词，他用Google搜索了一些资料之后，总算是对单一职责原则有了一些认识，于是打算对ImageLoader进行一次重构。这次小民不敢过于草率，也是先画了一幅UML图，如图 1 所示：
ImageLoader代码修改如下所示：
/** * 图片加载类 */public class ImageLoader { // 图片缓存 ImageCache mImageCache = new ImageCache() ; // 线程池,线程数量为CPU的数量 ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime. getRuntime().availableProcessors()); // UI Handler Handler mUiHandler = new Handler(Looper.getMainLooper()); private void updateImageView(final ImageView imageView, final Bitmap bmp) { mUiHandler.post(new Runnable() { @Override public void run() { imageView.setImageBitmap(bmp); } }); } //加载图片 public void displayImage(final String url, final ImageView imageView) { Bitmap bitmap = mImageCache.get(url); if (bitmap != null) { imageView.setImageBitmap(bitmap); return; } imageView.setTag(url); mExecutorService.submit(new Runnable() { @Override public void run() { Bitmap bitmap = downloadImage(url); if (bitmap == null) { return; } if (imageView.getTag().equals(url)) { updateImageView(imageView, bitmap); } mImageCache.put(url, bitmap); } }); } public Bitmap downloadImage(String imageUrl) { Bitmap bitmap = null; try { URL url = new URL(imageUrl); final HttpURLConnection conn = (HttpURLConnection) url.openConnection(); bitmap = BitmapFactory.decodeStream(conn.getInputStream()); conn.disconnect(); } catch (Exception e) { e.printStackTrace(); } return bitmap; }}
并且添加了一个ImageCache类用于处理图片缓存，具体代码如下：
public class ImageCache { // 图片LRU缓存 LruCache<String, Bitmap>mImageCache; public ImageCache() { initImageCache(); } private void initImageCache() { // 计算可使用的最大内存 final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024); // 取四分之一的可用内存作为缓存 final int cacheSize = maxMemory / 4; mImageCache = new LruCache<String, Bitmap>(cacheSize) { @Override protected int sizeOf(String key, Bitmap bitmap) { return bitmap.getRowBytes() * bitmap.getHeight() / 1024; } }; } public void put(String url, Bitmap bitmap) { mImageCache.put(url, bitmap) ; } public Bitmap get(String url) { return mImageCache.get(url) ; } }
如图 1 和上述代码所示，小民将ImageLoader一拆为二，ImageLoader只负责图片加载的逻辑，而ImageCache只负责处理图片缓存的逻辑，这样ImageLoader的代码量变少了，职责也清晰了；当与缓存相关的逻辑需要改变时，不需要修改ImageLoader类，而图片加载的逻辑需要修改时也不会影响到缓存处理逻辑。主管在审核了第一次重构之后，对工作给予了表扬，大致意思是结构变得清晰了许多，但是可扩展性还是比较欠缺。虽然没有得到主管的完全肯定，但也是颇有进步，再考虑到自己确实有所收获，原本沮丧的心里也略微地好转起来。
从上述的例子中我们能够体会到，单一职责所表达出的用意就是“单一”二字。正如上文所说，如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体的业务逻辑而定。但是，它也有一些基本的指导原则，例如，两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断地审视自己的代码，根据具体的业务、功能对类进行相应拆分，这是程序员优化代码迈出的第一步。
让程序更稳定、更灵活——开闭原则
开闭原则的英文全称是Open Close Principle，缩写是OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。
软件开发过程中，最不会变化的就是变化本身。产品需要不断地升级、维护，没有一个产品从第一版本开发完就再没有变化了，除非在下个版本诞生之前它已经被终止。而产品需要升级，修改原来的代码就可能会引发其他的问题。那么，如何确保原有软件模块的正确性，以及尽量少地影响原有模块，答案就是，尽量遵守本文讲述的开闭原则。
勃兰特·梅耶在 1988 年出版的《面向对象软件构造》一书中提出这一原则——开闭原则。这一想法认为，程序一旦开发完成，程序中一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码。显然，梅耶的定义提倡实现继承，已存在的实现类对于修改是封闭的，但是新的实现类可以通过覆写父类的接口应对变化。
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4 个字说明OCP原则并不是说绝对不可以修改原始类的。当我们嗅到原来的代码“腐化气味”时，应该尽早地重构，以便使代码恢复到正常的“进化”过程，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。
构建扩展性更好的系统——里氏替换原则
里氏替换原则英文全称是Liskov Substitution Principle，缩写是LSP。LSP的第一种定义是：如果对每一个类型为S的对象 O1 ，都有类型为T的对象 O2 ，使得以T定义的所有程序P在所有的对象 O1 都代换成 O2 时，程序P的行为没有发生变化，那么类型S是类型T的子类型。上面这种描述确实不太好理解，我们再看看另一个直截了当的定义。里氏替换原则第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。
我们知道，面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。里氏替换原则简单来说就是，所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。说了那么多，其实最终总结就两个字：抽象。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。优点有以下几点：
- 代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
- 子类与父类基本相似，但又与父类有所区别；
- 提高代码的可扩展性。
继承的缺点：
- 继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
- 可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法。
事物总是具有两面性，如何权衡利与弊都是需要根据具体情况来做出选择并加以处理。里氏替换原则指导我们构建扩展性更好的软件系统里氏替换原则就是建立抽象，通过抽象建立规范，具体的实现在运行时替换掉抽象，保证系统的扩展性、灵活性。开闭原则和里氏替换原则往往是生死相依、不弃不离的，通过里氏替换来达到对扩展开放，对修改关闭的效果。然而，这两个原则都同时强调了一个OOP的重要特性——抽象，因此，在开发过程中运用抽象是走向代码优化的重要一步。
让项目拥有变化的能力——依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle，缩写是DIP。依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次模块的实现细节的目的，依赖模块被颠倒了。这个概念有点不好理解，这到底是什么意思呢？
依赖倒置原则有以下几个关键点：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
- 抽象不应该依赖细节；
- 细节应该依赖抽象。
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字new产生一个对象。高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在 Java语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象精髓之一，也就是上面两节强调的抽象。
如果类与类直接依赖于细节，那么它们之间就有直接的耦合，当具体实现需要变化时，意味着要同时修改依赖者的代码，这限制了系统的可扩展性。要想让系统更为灵活，抽象似乎成了我们唯一的手段。
系统有更高的灵活性——接口隔离原则
接口隔离原则英文全称是InterfaceSegregation Principles，缩写是ISP。ISP的定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
接口隔离原则说白了就是，让客户端依赖的接口尽可能地小，这样说可能还是有点抽象，我们还是以一个示例来说明一下。在此之前我们来说一个场景，在Java 6 及之前的JDK版本，有一个非常讨厌的问题，那就是在使用了OutputStream或者其他可关闭的对象之后，我们必须保证它们最终被关闭了，
Bob大叔（Robert C Martin）在 21 世纪早期将单一职责、开闭原则、里氏替换、接口隔离以及依赖倒置（也称为依赖反转）5 个原则定义为SOLID原则，作为面向对象编程的 5 个基本原则。当这些原则被一起应用时，它们使得一个软件系统更清晰、简单，最大程度地拥抱变化。SOLID被典型地应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发基本原则的重要组成部分。在经过学习之后，我们发现这几大原则可以化为这几个关键词：抽象、单一职责、最小化。那么，在实际开发过程中如何权衡、实践这些原则，大家需要在实践中多思考与领悟，正所谓“学而不思则罔，思而不学则殆”，只有不断地学习、实践、思考，才能够在积累的过程中有一个质的飞越。
更好的可扩展性——迪米特原则
迪米特原则英文全称为Law of Demeter，缩写是LOD，也称为最少知识原则（Least Knowledge Principle）。虽然名字不同，但描述的是同一个原则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
迪米特法则还有一个英文解释是Only talk to your immedate friends，翻译过来就是：只与直接的朋友通信。什么叫做直接的朋友呢？每个对象都必然会与其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，如组合、聚合、依赖等。
小结
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。
（本文节选自何红辉，关爱民作品《Android 源码设计模式解析与实战》（第2版））