设计模式的原则

一、单一职责原则

判断：如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的的职责。

违背的代价：一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

二、开放-封闭原则

定义：软件实体（类、模块、函数等等）对扩展是开放的，对更改是封闭的，即可以被扩展，但是不能被修改。

具体操作：面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

困境：如果发现现有代码必须更改，就要对现有代码进行重构，使得在下次增加类似需求时，不会违背“开发-封闭”原则。

三、依赖倒转原则

A. 高层模块不应该依赖低层模块。两个都应该依赖抽象。

B. 抽象不应该依赖细节，细节应该依赖于抽象。即针对接口编程，不要对实现编程。

场景：主板和内存、CPU之间就很好的遵循了相应的原则，即CPU和主板只要满足相应的接口设计，就能放在一起使用，而不管CPU是Intel实现的，还是AMD实现的。

关键点：在上层和下层之间加一层接口类，从而使得下层的变化不必影响上层，上层的变化也不会导致下层的更改。大家都依赖这个接口类，只要保证接口类的正常运转，就可以灵活的修改。

四、迪米特法则

如果两个类不必彼此直接通信（即不需要知道彼此是否存在），那么这两个类就不应当直接相互作用。如果其中一个类需要调用另一个类的某一个方法，就需要通过第三者转发这个调用。

五、合成/聚合复用原则

尽量使用合成/聚合，而不是类继承。因为继承是一种强耦合的关系，父类变，子类就必须要变。