共计 3378 个字符，预计需要花费 9 分钟才能阅读完成。
1. 繁多职责准则（Single Responsibility Principle – SRP）
原文：There should never be more than one reason for a class to change.
译文：永远不应该有多于一个起因来扭转某个类。
了解：对于一个类而言，应该仅有一个引起它变动的起因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事件。
利用：当咱们做零碎设计时，如果发现有一个类领有了两种的职责，那就问本人一个问题：能够将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事件太多！
2. 凋谢关闭准则（Open Closed Principle – OCP）
原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.
译文：软件实体，如：类、模块与函数，对于扩大应该是凋谢的，但对于批改应该是关闭的。
了解：简言之，对扩大凋谢，对批改关闭。换句话说，能够去扩大类，但不要去批改类。
利用：当需要有改变，要批改代码了，此时您要做的是，尽量用继承或组合的形式来扩大类的性能，而不是间接批改类的代码。当然，如果可能确保对整体架构不会产生任何影响，那么也没必要搞得那么简单了，间接改这个类吧。
3. 里氏替换准则（Liskov Substitution Principle – LSP）
原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
译文：应用基类的指针或援用的函数，必须是在不知情的状况下，可能应用派生类的对象。
了解：父类可能替换子类，但子类不肯定能替换父类。也就是说，在代码中能够将父类全副替换为子类，程序不会报错，也不会在运行时呈现任何异样，但反过来却不肯定成立。
利用：在继承类时，务必重写（Override）父类中所有的办法，尤其须要留神父类的 protected 办法（它们往往是让您重写的），子类尽量不要裸露本人的 public 办法供外界调用。
4. 起码常识准则（Least Knowledge Principle – LKP）
原文：Only talk to you immediate friends.
译文：只与你最间接的敌人交换。
了解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，肯定要做到：低耦合，高内聚。
利用：在做零碎设计时，不要让一个类依赖于太多的其余类，需尽量减小依赖关系，否则，您死都不晓得本人怎么死的。
5. 接口隔离准则（Interface Segregation Principle – ISP）
原文：The dependency of one class to another one should depend on the smallest possible interface.
译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
了解：不要对外裸露没有实际意义的接口。也就是说，接口是给他人调用的，那就不要去尴尬他人了，尽可能保障接口的实用性吧。她好，我也好。
利用：当须要对外裸露接口时，须要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您未来要多做一件事件，何苦要给本人找事做呢。
6. 依赖倒置准则（Dependence Inversion Principle – DIP）
原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
译文：高层模块不应该依赖于低层模块，它们应该依赖于形象。形象不应该依赖于细节，细节应该依赖于形象。
了解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看实质，那是反向依赖，即依赖倒置（程序员思维）。
利用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量应用接口来编程吧。
将以上六大准则的英文首字母拼在一起就是 SOLID（稳固的），所以也称之为 SOLID 准则。
只有满足了这六大准则，能力设计出稳固的软件架构！但它们毕竟只是准则，只是四人帮给咱们的倡议，有些时候咱们还是要学会灵活应变，千万不要生吞活剥，否则只会把简略问题复杂化，切记！
- 补充设计准则
1. 组合 / 聚合复用准则（Composition/Aggregation Reuse Principle – CARP）
当要扩大类的性能时，优先思考应用组合，而不是继承。这条准则在 23 种经典设计模式中频繁应用，如：代理模式、装璜模式、适配器模式等。可见江湖位置十分之高！
2. 无环依赖准则（Acyclic Dependencies Principle – ADP）
当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将呈现循环依赖。在设计中应该防止这个问题，可通过引入“中介者模式”解决该问题。
3. 独特封装准则（Common Closure Principle – CCP）
应该将易变的类放在同一个包里，将变动隔离进去。该准则是“凋谢 - 关闭准则”的延生。
4. 独特重用准则（Common Reuse Principle – CRP）
如果重用了包中的一个类，那么也就相当于重用了包中的所有类，咱们要尽可能减小包的大小。
5. 好莱坞准则（Hollywood Principle – HP）
好莱坞明星的经纪人个别都很忙，他们不想被打搅，往往会说：Don’t call me, I’ll call you. 翻译为：不要分割我，我会分割你。对应于软件设计而言，最驰名的就是“管制反转”（或称为“依赖注入”），咱们不须要在代码中被动的创建对象，而是由容器帮咱们来创立并治理这些对象。
- 其余设计准则
1. 不要反复你本人（Don’t repeat yourself – DRY）
不要让反复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
2. 放弃它简略与傻瓜（Keep it simple and stupid – KISS）
不要让零碎变得复杂，界面简洁，性能实用，操作不便，要让它足够的简略，足够的傻瓜。
3. 高内聚与低耦合（High Cohesion and Low Coupling – HCLC）
模块外部须要做到内聚度高，模块之间须要做到耦合度低。
4. 常规优于配置（Convention over Configuration – COC）
尽量让常规来缩小配置，这样能力进步开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
5. 命令查问拆散（Command Query Separation – CQS）
在定义接口时，要做到哪些是命令，哪些是查问，要将它们拆散，而不要揉到一起。
6. 关注点拆散（Separation of Concerns – SOC）
将一个简单的问题拆散为多个简略的问题，而后一一解决这些简略的问题，那么这个简单的问题就解决了。难就难在如何进行拆散。
7. 契约式设计（Design by Contract – DBC）
模块或零碎之间的交互，都是基于契约（接口或形象）的，而不要依赖于具体实现。该准则倡议咱们要面向契约编程。
8. 你不须要它（You aren’t gonna need it – YAGNI）
不要一开始就把零碎设计得非常复杂，不要陷入“适度设计”的深渊。应该让零碎足够的简略，而却又不失扩展性，这是其中的难点。
