引言
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象六大原则就是我们走向灵活软件之路所迈出的第一步。
- 单一职责原则：优化代码第一步。既就一个类而言，应该有且仅有一个引起它变化的原因。
- 开闭原则：让程序更稳定，更灵活；软件中的对象（类、模块、函数等）应该对于扩展是开放的，但对于修改是封闭的。
- 里氏替换原则：构建扩展性更好的系统。
- 依赖倒置原则：让项目拥有变化能力，既依赖抽象，不依赖具体实现。
- 接口隔离原则：系统拥有更高灵活性。
- 迪米特原则（最少知识原则）：一个对象应对其他对象有最少的了解。
单一职责原则（SRP，Single Responsibility Principle）
单一职责所表达出的用意就是“单一”二字，它的定义是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。《设计模式之禅》中说的：“这是一个备受争议却又及其重要的原则。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的”。因为单一职责的划分界限并不是总是那么清晰，很多时候都是需要靠个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。
如何划分一个类，一个函数的职责？每个人的经验不同，观点看法也不同，故视具体任务而定。但它也有一些基本的知道原则：
- 两个完全不一样的功能就不应该放到同一个类中。
- 一个类中应该是一组相关性很高的函数、数据的封装。
开发人员需要在开发过程中不断地审视自己的代码，根据具体的业务、功能对类进行相应的拆分。
开闭原则（OCP，Open Close Principle）
开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
勃兰特·梅耶在1988年出版的《面向对象软件构造》中提倡：
- 新的或改变的特性应通过新建不同的类实现，新建的类可通过继承的方式来重用原类的代码。
- 已存在的实现类对于修改是封闭的，但新的实现类可通过 覆写父类的接口 应对变化。
- 开闭原则知道我们，当软件需变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4个字说明OCP原则并不是说绝对不可以修改原始类的，当我们嗅到原来的代码“腐化气味”时，应该尽早地重构，以使得代码恢复到正常的“进化”轨道，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。
里氏替换原则（LSP，Liskov Substitution Principle）
里氏替换原则第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。里氏替换原则通常与开闭原则是生死相依、不离不弃的，通过里氏替换来达到对扩展开放，对修改关闭的效果。
我们知道，面向对象的语言的三大特点是继承、封装、多态，里氏替换原则就是依赖于继承、多态这两大特性。通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。说了那么多，其实最终总结就两个字：抽象。
// 窗口类
public class Window {
public void show(View child){
child.draw();
}
}
// 建立视图抽象，测量视图的宽高为公用代码，绘制交给具体的子类
public abstract class View {
public abstract void draw();
public void measure(int width, int height) {
// 测量视图的大小
}
}
public class Button extends View {
public draw() {
// 绘制按钮
}
}
上述例子中，任何继承自 View 类的子类都可以设置给 show 方法，既里氏替换。这样千变万化的 View 传递给 Window，Window 只管组织 View，并显示在屏幕上。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。
优点如下：
- 代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
- 子类与父类基本相似，但又与父类有所区别；
- 提高代码的可扩展性。
继承的缺点：
- 继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
- 可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法。
事物总是具有两面性，如何权衡利与弊都是需要根据具体场景来做出选择并加以处理。
依赖倒置原则（DIP，Dependence Inversion Principle）
一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节。依赖倒置原则的几个关键点：
- 高层模块不应该依赖低层模块，两者都应以来其抽象；
- 抽象不应该依赖细节
- 细节应依赖抽象
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字 new 产生一个对象。高层模块就是调用端，低层模块就是具体实现类。
依赖倒置原则在 Java 语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象精髓之一，也就是上面两节强调的抽象。
/*
* 设计一款实现图片缓冲功能的接口，具体的缓冲实现方式、细节，根据实际情况编写。
*/
public interface ImageChache { // ImageCache 缓存抽象
public Bitmap get(String url);
public void put(String url, Bitmap bmp);
}
public class MemoryCache implements ImageCache {
// 根据实际需求，再实现具体细节
}
public class ImageLoader {
// 图片缓存类，依赖抽象，不依赖细节
ImageCache mCache = new MemoryCache();
public void displayImage(String url, ImageView imageView) {
Bitmap bmp = mCache.get(url);
if(null == bmp){
downloadImageAsync(url, imageView);
} else {
imageView.setImageBitmap(bmp);
}
}
public void setImageCache(ImageCache cache) {
mCache = cache;
}
}
当需求发生变更时，只需要实现ImageCahce类或者继承其他已有的ImageCache子类完成相应的缓存功能，然后将具体的实现注入到ImageLoader即可实现缓存功能的替换，这就保证了缓存系统的高可扩展性，拥有了拥抱变化的能力，而这一切的基本指导原则就是我们的依赖倒置原则。
接口隔离原则（ISP，Interface Segregation Principles）
接口隔离原则定义是：客户端不应该依赖它不需要的接口。另一种定义是：类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。IPS的目的是系统解开耦合。
ImageLoader只需要知道该缓存对象有存、取缓存图片的接口即可，其他的一概不管，这就使得缓存功能的具体实现对ImageLoader具体的隐藏。这就是用最小化接口隔离了实现类的细节，也促使我们将庞大的接口拆分到更细粒度的接口当中，这使得我们的系统具有更低的耦合性，更高的灵活性。
迪米特原则（LOD，Law of Demeter）
也称为最少知识原则（Least Knowledge Principle），一个对象应对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现、如何复杂都与调用者或者依赖者没关系，调用者或者依赖者只需要知道他需要的方法即可，其他的我一概不关心。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
总结
Robert C Martin在21世纪早期将单一职责、开闭原则、里氏替换、接口隔离以及依赖倒置（也称为依赖反转）5个原则定义为SOLID原则，指代了面向对象编程的5个基本原则。当这些原则被一起应用时，它们使得一个软件系统更清晰、简单、最大程度地拥抱变化。SOLID被典型地应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发基本原则的重要组成部分。在经过学习之后，我们发现这几大原则最终就可以化为这几个关键词：抽象、单一职责、最小化。那么在实际开发过程中如何权衡、实践这些原则，是大家需要在实践中多思考与领悟，正所谓”学而不思则罔，思而不学则殆”，只有不断地学习、实践、思考，才能够在积累的过程有一个质的飞越。
参考书籍：
- 《设计模式之禅》
- 《Android源码设计模式解析与实战》