六大设计原则 (设计模式之禅读书笔记)
开闭原则（The Open Closed Principle）
软件应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
单一职责原则（The Single Responsibility Principle）
定义：应该有且仅有一个原因引起类的变更。
迪米特原则 （The Least Knowledge Principle）
最少知道原则
核心观念是类间解耦，低耦合，只有弱耦合以后，类的复用率才可以提高。
缺点：产生中转或跳转类，系统复杂性提高，增加维护难度。
一个类只和朋友交流，不与陌生类交流。
朋友类：出现在成员变量或方法输入输出参数中的类称为成员朋友类而出现在方法体内部的类不属于朋友类。
类要做到高内聚低耦合，尽量减少public属性方法。
关于方法放到哪个类中的问题：
如果一个方法放到本类中，既不增加类间关系，也不对本类产生负面影响，那就放置在本类中。
系统中如果一个类跳转两次以上才能访问另一个类就需要进行重构。
里氏替换原则 (The Liskov Substitution Principle)
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。
在类中调用其它类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了lsp原则。
如果子类不能完整的实现父类的方法，或者父类的某些方法在子类中已经发生畸变，则建议断开父子继承关系，采用依赖，继承，组合等关系代替继承。
覆盖或实现父类的方法时输入参数可以被放大。
覆盖或实现父类的方法时输出参数可以被缩小。
采用里氏替换原则的目的就是增强程序的健壮性，版本升级时可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际的项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。
依赖倒置原则 (The Dependency Inversion Principle)
高层模块不应该依赖低层模块，两者都应该依赖其抽象。
抽象不应该依赖细节。
细节应该依赖抽象。
面向接口编程。
两个类之间有依赖关系，只要指定出两者的接口，就可以独立开发了。
测试驱动开发，适合研发类项目或者项目成员整体水平比较低的情况。
抽象是对实现的约束，对依赖者而言也是一种契约。
1 每个类尽量都有接口或者抽象类。
面向接口编程
编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统中的事物间的依赖，倒置就是从这里产生的。
接口隔离原则 (The Interface Segregation Principle)
实例接口 class
类接口 interface
客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上。
建立单一接口，不要建立臃肿庞大的接口。
根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
通过业务逻辑压缩接口中的public方法，尽量让接口达到满身筋骨肉，而不是肥嘟嘟的一大堆方法。
