设计原则

学习了好几遍的设计模式，为了防止自己遗忘，做一下笔记，总结一下，自己学习过的设计模式，如果有什么错误，敬请谅解。

单一职责原则

描述:A class or module should have a single responsibility
中文:一个类或者模块只负责完成一个职责(或者功能)。
注意，这个原则描述的对象包含两个，一个是类（class），一个是模块（module）。关于这两个概念，在专栏中，有两种理解方式。一种理解是：把模块看作比类更加抽象的概念，类也可以看作模块。另一种理解是：把模块看作比类更加粗粒度的代码块，模块中包含多个类，多个类组成一个模块。

开闭原则

描述:software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification.
中文:软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。
这个描述比较简略，如果我们详细表述一下，那就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。

里氏替换原则

描述:Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.
中文：子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

接口隔离原则

描述:Clients should not be forced to depend upon interfaces that they do not use。
中文:客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者.

依赖反转原则

描述:High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.
中文:高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）

KISS 原则

描述:Keep It Simple and Stupid.
中文:尽量保持简单。

YAGNI 原则

描述:You Ain’t Gonna Need It
中文:你不会需要它
这条原则的核心思想就是：不要做过度设计.

DRY 原则

描述:Don’t Repeat Yourself。
中文：不要重复自己，理解为:不要写重复的代码.

迪米特法则

描述:Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
中文:每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。

先把所有的法则写在这里，接下来我总结各种模式的时候，在总结一下各种模式满足了什么原则!

推荐一个零声学院免费教程，个人觉得老师讲得不错，
分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，
fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，
TCP/IP，协程，DPDK等技术内容，点击立即学习:
服务器
音视频
dpdk
Linux内核