《Android源码设计模式解析与实战》读书笔记（一）——面向对象的六大原则

写代码很容易，但是写出简单易懂好修改的代码实在。如何优化代码，设计模式是关键，所以最近开始啃书，在这里记录一下读书笔记，大部分是摘录，也有自己的总结和心得，写给自己。

第一章、面向对象的六大原则

1.单一职责原则

Single Responsibility Principle，SRP，其定义是：就一个类而言，应该仅有一个引起它变化的原因。
两个完全不一样的功能不应该放在一个类中，比如一个带缓存的图片加载器，图片加载是一个功能，图片缓存又是一个功能，可以分为两个类。
根据具体业务、具体功能对类进行相应拆分，是优化代码的第一步。

2.开闭原则

Open Close Principle，OCP，其定义是：软件中的对象（类、模块、方法等）应该对于扩展是开放的，但是，对于修改是封闭的。
开闭原则是Java世界中最基础的设计原则，可以理解为需要改变软件时，应该尽量采取扩展的方式而不是修改原来的代码。当然，这只是一个理想化的情况，实际开发中，修改原来的代码和扩展代码往往是同时存在的。
“程序一旦开发完成，程序中一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类来实现，新建的类可以通过继承的方式来重用原类的代码。”——《面向对象软件构造》。也就是已存在的实现类对于修改是封闭的，但是新的实现类可以通过覆写父类的方法来应对变化。比如一个图片缓存类，刚开始是用的Lru缓存，后来发现需要用SD卡缓存，或者两种缓存都需要（先判断Lru缓存中是否有图片，如果有则加载，没有则再去SD卡缓存中读），这种情况下应该定义一个图片缓存的接口，各个缓存方式的类需实现该接口并实现该接口中的方法。这样的好处就是，当你需要改变缓存方式时，不用去改变原来的类，而是可以新加入一个类，从而不影响原来的代码。
遵循开闭原则的重要手段应该是通过抽象。

3.里氏替换原则

Liskov Substitution Principle，LSP，其定义有两种，第一种：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都替换O2时，程序P的行为不会发生变化，那么类型S就是类型T的子类。这第一种定义实在是不好理解，再来看看第二种定义：所有引用基类的地方必须能透明地使用其子类的对象。
通俗点说，里氏替换原则就是只要父类能出现的地方，子类就可以出现，而且替换成子类后不会产生任何错误或异常，使用者可能根本不知道它是父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必能够适应。总结为两个字就是：抽象。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这一特性，继承的优缺点很明显。
优点：
1）.代码重用，减少类的创建成本，因为每个子类都可以拥有父类的方法和属性。
2）.子类与父类基本相似，但与父类又有所区别。
3）.提高代码的可扩展性。
缺点：
1）.继承是侵入性的，只要继承就必须拥有父类的所有属性和方法。
2）.可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的所有属性和方法。
举个例子，刚才所说的图片缓存方式可以定义为一个接口ImageCache，各个缓存方式则是实现该接口的实现类，如Lru缓存MemoryCache、SD卡缓存SDCardCache、双缓存DoubleCache，它们都可以替换ImageCache，并且保证行为的正确性。ImageCache接口定义了接口规范，而它的实现类则根据接口规范实现了相应功能，这就保证了ImageCache的可扩展性。
里氏替换原则就是建立抽象，通过抽象建立规范，根据规范实现功能后，再替换掉抽象，保证程序的可扩展性、灵活性。里氏替换原则和开闭原则往往是生死相依的，通过里氏替换来达到开发扩展，封闭修改的效果。这两个原则都强调了面向对象编程的一个特性——抽象。
抽象是走向代码优化的重要一步。

4.依赖倒置原则

Dependence Inversion Principle，DIP，它指代了一种特定的解耦方式，使得高层次的模块不依赖于低层次的模块的实现，依赖模块被颠倒了。
依赖倒置原则的概念同样不好理解，但是请记住以下几个关键点：
1）.高层次模块不应该依赖于低层次模块，二者应该都依赖其抽象。
2）.抽象不应该依赖于细节。
3）.细节应该依赖于抽象。
在Java语言中，高层次模块就是调用端，低层次模块就是具体功能实现类，抽象是指接口或者抽象类，细节则是其实现类。所以，通过Java语言来解释依赖倒置原则就是：模块之间的依赖是通过抽象，实现类之间不能发生直接依赖关系，实现类之间的依赖关系是通过接口或者抽象类产生的。
为什么应该遵循依赖倒置原则？如果类与类直接依赖于细节，它们之间就会有直接的耦合，当具体实现发生变化的时候，依赖者的代码也得进行修改，这就限制了程序的可扩展性。
比如上面带缓存的图片加载器，如果直接依赖于某一个具体的缓存实现类，当需要换一种缓存方式的时候，既要修改原来的缓存类或者创建新的缓存类，又要修改加载器中的使用缓存的代码。如果依赖其抽象，则只需要重新创建实现类并将具体实现注入到加载器中就可以实现缓存方式的替换。保证程序的可扩展性。
想让程序更加灵活，抽象似乎成为了唯一手段。

5.接口隔离原则

Interface Segregation Principle，ISP，其定义是：客户端不应该依赖它不需要的接口，又或者说类与类之间的依赖关系应该建立在最小的接口上。
接口隔离原则意在将非常庞大、臃肿的接口拆分为更小更具体的接口，让客户端只需要知道它们感兴趣的方法。其目的就是让程序解开耦合，从而容易重构、更改和重新部署。
接口隔离原则说白了就是让客户端依赖的接口尽可能小，比如上面的图片缓存接口ImageCache，图片加载类ImageLoader只需要知道这个缓存对象有存取缓存图片的接口即可，其余的一概不管，所以缓存功能的具体实现并没有暴露给ImageLoader，这就隔离了实现类的细节，让系统具有更低的耦合性，更高的灵活性。

6.迪米特原则

Law of Demeter，LOD，也称为最少知识原则（Least Knowledge Principle，LKP），其定义是：一个对象应该对其他对象有最少的了解。
通俗的讲，就是一个类应该对自己需要耦合或者调用的类知道得最少，类的内部如何实现，与调用者或者说是依赖者没有关系，调用者或者依赖者只需要知道它所需要的方法即可，其余的一概不管。类与类之间关系越密切，耦合度就越大，当其中一个类改变时，对另一个类的影响也就越大。
迪米特原则的英文解释：Only talk to your immediate friends。翻译过来就是只与直接的“朋友”联系，我的理解就是，一个类A需要调用另一个类B时，只能跟类B进行耦合，而类B是如何具体实现的，是否和别的类又产生了耦合，则不需要管，类B就是类A的直接"朋友"，类B的一切细节都隐藏在这个直接“朋友”的外衣下，使系统具有更低的耦合性和更好的可扩展性。

7.总结

通过对面向对象的六大原则的基本了解，我们知道在设计程序架构的时候，应该在满足需求且不破坏系统稳定性的前提下，保证程序的高可扩展性、高内聚、低耦合的特点。虽然这只是一个理想情况，但是我们应该努力向这个方向去设计，遵循六大原则，就是设计架构的第一步。
这六大原则，从中也可以抽取出一些关键字，比如单一职责，抽象，最小化，这就很有助于我们从什么方向切入，从什么方向去设计架构。以前小不懂事，总觉得实现了某个功能就很厉害了，但是丝毫没有考虑到程序的可扩展性和健壮性，只是考虑了第一版，却没有考虑到后续的维护和升级，所以，遵循某些原则，让程序有一个清晰的结构是很有必要的。