一、关于设计原则

关于设计原则，主流的为了六大原则，但是有的人开始说七大原则，有的是十大原则。个人认为，其他不同的设计原则，都是基于六大设计原则基础上进行更细的描述。

二、常用六大原则

2.1 单一职责原则（Single Responsibility Principle, SRP)

对功能进行分类，代码进行解耦.应该有且仅有一个原因引起类的变更。简单点说，一个类，最好只负责一件事，只有一个引起它变化的原因

2.2 开闭原则（Open Close Principle/OCP）

开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。这个原则有两个特性，一个是说“对于扩展是开放的”，另一个是说“对于更改是封闭的”。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这就是“开放-封闭原则”的精神所在

2.3 里氏替换原则（Liskov Substitution principle）

“Subtypes must be substitutable for their base types”。也就是，子类必须能够替换成它们的基类。在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。

2.4 依赖倒置原则（Dependence Inversion Principle）

设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。

2.5 接口隔离原则（Interface Segregation Principle, ISP）

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

2.6 迪米特法则（Law of Demeter, LoD）

迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项目设计提出的，它要求一个对象应该对其他对象有最少的了解，所以迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP）。

• 迪米特法则的意义在于降低类之间的耦合。由于每个对象尽量减少对其他对象的了解，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

• 值得一提的是，这一法则却不仅仅局限于计算机领域，在其他领域也同样适用。比如，美国人就在航天系统的设计中采用这一法则。

三、其他设计原则

3.1 委托原则

不要自己做所有的事情，可以委托给相应的类去完成。

3.2 控制反转

不要主动要求依赖，因为它已经由框架提供给你。比如Spring框架等，这样的设计原则妙处在于，它是由DI注入框架的注入匹配需要的类，这样更容易进行测试维护，因为创建对象的代码都集中在框架，而客户端代码是不参与的。

3.3 DRY (不要重复你自己)

这是指不写重复的代码，取而代之是使用抽象共性的东西。如果超过一次使用硬编码，那么就要考虑将其公开为final修饰的不变量；如果你在两个以上地方有相同的代码块，那么就要考虑使其成为一个单独的方法。SOLID设计原理的好处是在维护。值得注意的是重复的不是指代码，而是对于功能而言的。

3.4 组合胜过于继承

如果可能的话组合composition总是胜过继承。组合比继承拥有更多的灵活性。组合允许在运行时设置属性，并通过使用接口来实现，我们可以使用多态在类运行时改变类的行为，从而提供更好的接口实现。