【设计模式】原则篇

1.单一职责原则：

就一个类而言，应该仅有一个引起它变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者影响这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏

---

2.开放-封闭原则

软件实体（类、模块、函数等）应该可以扩展，但是不可以修改。

解决的问题：
怎样的设计才能面对需求的改变可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？
面对需求，对成宿的改动是通过添加新代码进行的，而不是更改现有的代码、这是这个原则的关键。
重构程序，添加一个抽象的类，通过一些面向对象的操作，如继承，多态来隔离具体方法与请求操作的类进行耦合，需求依然满足，还可以应对变化。

---

3.依赖倒转原则——-面向接口编程

A.高层模块不应该依赖底层模块，两个都应该依赖抽象。
B.抽象不应该依赖细节，细节应该依赖抽象。

具体的例子：
PC里如果CPU、内存、硬盘都需要依赖具体的主板，主板一坏，所有的部件就没有了，这显然不合理。反过来，如果内存坏了，也不应该造成其他部件不能用才对。如果，高层和底层模块都依赖抽象，具体一点就是接口和抽象类，只要接口是稳定的，那么任何一个的更改都不会使得其他的部件收到影响，这就使得高层和底层的模块可以很容易地被复用。

---

4.里氏代换原理——-面向对象的设计

子类型必须能够替换掉它们的父类型。
只有当子类可以替换掉父类，软件单位功能不会受到影响时，父类才能真正被复用，而子类也能够在父类的基础上添加新的行为。

---

5.迪米特法则

如果两个类不必批次直接通信，那么这两个类就不应当发生直接的额相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

在类的结构设计上，每个类都应当尽量降低成员的访问。强调了类之间的松耦合。耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。

---

如您所见，小编初学，以上是我的学习摘抄，缺乏自己的总结，要是日后有感，再做进一步的补充~