《设计模式之禅》读书笔记（一）
六大设计原则
单一职责原则
定义：应该有且仅有一个原因引起类的变更。
举例：属性和行为拆分，例如 setPassword(String password) 和 changePassword(String password)。
单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。 对于单一职责原则，建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
里氏替换原则
定义：所有引用基类的地方必须能透明地使用其子类的对象。
1.子类必须完全实现父类的方法。
2.子类可以有自己的个性。
3.覆盖或实现父类的方法时输入参数可以被放大。（这里要注意覆写（Override）和重载（Overload）的区别，子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。）
4.覆写或实现父类的方法时输出结果可以被缩小。
在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。
依赖倒置原则
定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
依赖的三种传递方式：构造函数传递依赖对象；Setter方法传递依赖对象；接口声明依赖对象。
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。
1.每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
2.变量的表面类型尽量是接口或者是抽象类。在高层业务逻辑，它对低层模块的依赖都建立在抽象上，例如使用的IDriver和ICar这样的抽象类。
3.任何类都不应该从具体类派生。
4.尽量不要覆写基类的方法。
5.结合里氏替换原则使用。接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
接口隔离原则
定义：客户端不应该依赖他不需要的接口；类间的依赖关系应该建立在最小的接口上。
概括：建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。
实践：把一个臃肿的接口变更为两个独立的接口所依赖的原则就是接口隔离原则。接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。
原则：接口要尽量小；接口要高内聚；定制服务；接口设计是有限度的。
迪米特法则
定义：最少知识原则（LeastKnowledge Principle，LKP），一个对象应该对其他对象有最少的了解。
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。尽量不要对外公布太多的public方法和非静态的public变量，多使用private、package-private、protected等访问权限。
开闭原则
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
变化归纳为以下三种类型：
1.逻辑变化。只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是ab+c，现在需要修改为ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。
2.子模块变化。一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的。
3.可见视图变化。可见视图是提供给客户使用的界面，还是可以通过扩展来完成变化。
实践：
1.抽象约束。抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。
2.元数据（metadata）控制模块行为。尽量使用元数据来控制程序的行为，减少重复开发。元数据是用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。
3.制定项目章程。
4.封装变化。对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
