设计模式之面向对象

写代码一般原则

界面逻辑与业务逻辑分离。

使用继承与多态提高扩展性和复用性。

对于项目刚开始的时候，可以不进行抽象，但是如果需求改变的时候，需要创建抽象来隔离以后可能发生的同类变化，也就是说对于程序的改动，是通过增加新代码，而不是修改旧代码来完成。

单一职责原则

对于一个类来说，应该只有一个引起它变化的原因。职责过多会导致高度耦合。

开放封闭原则

对于扩展开放，对于修改封闭。

里氏替换原则

子类型必须能够替换掉它们的父类型。这就意味着，如果一个软件实体里使用的是一个父类的话，那么一定适用于其子类，而且替换后程序的行为不会变化。

因为子类的可替换性，所以使用父类类型的模块就可以不用修改实现同样的功能，实现了扩展性。

依赖倒转原则

1. 高层模块不应该依赖于底层模块。两者都应该依赖于抽象。
2. 抽象不应该依赖于细节，细节应该依赖于抽象。
   高层模块我理解是业务逻辑代码，底层模块我理解是封装的功能性代码，也就是说业务逻辑和功能代码应该依赖于抽象，两者中间应该抽离出一层接口，降低耦合。

迪米特法则：

如果两个类不必直接通信，则就不应该发生直接的相互作用，需要调用的时候可以通过第三者转发这个调用。

迪米特法则强调的前提是在类的结构设计上，每个类应当尽量降低成员的访问权限。尽量降低类与类之间的耦合，这样对一个类的修改就可以造成最小的影响，提高复用性可维护性。

合成/聚合复用原则（Composition/Aggregation Reuse Principle）

尽量使用合成/聚合，尽量避免使用类继承。

继承关系会导致子类实现与其父类有非常紧密的依赖关系，一方面如果父类修改了，则会导致子类的行为也发生改变。另一方面如果继承下来的实现不适合解决当前问题，则子类还需要去重写方法或者替换为其他类，就给复用性带来了一定的限制。

一般只有is-a的情况下才需要去继承，如果是添加特性之类可以考虑使用composition或者aggregation。aggregation是一种比较松散的拥有关系，composition是一种比较严格的拥有关系，部分和整体生命周期一致。

优先使用composition/aggregation可以保持类的封装性，保持类的继承层次在较小规模内，降低耦合。

敏捷开发原则

不要为代码添加基于猜测的、实际不需要的功能。在需要的时候才通过重构去实现。