六大设计原则

一、开闭原则。

开闭原则是总纲，要求一个软件实体，如类，模块和函数应该对外扩展开发，对内修改关闭。

• 解读：用抽象构建框架，用实现扩展细节。不以改动原有类的方式来实现新需求，而是应该以实现事先 抽象出来的接口（或具体类继承抽象类）的方式来实现。开闭原则认为：程序一旦开发完成，程序中的一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码
• 优点：开闭原则的优点在于可以在不改动原有代码的前提下给程序扩展功能。增加了程序的可扩展性，同时也降低了程序的维护成本。

二、单一职责原则。

一个类只允许有一个职责，即只有一个导致该类变更的原因。

• 解读：类职责的变化往往就是导致类变化的原因：也就是说如果一个类具有多种职责，就会有多种导致这个类变化的原因，从而导致这个类的维护变得困难。往往在软件开发中，随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去。不仅仅是类，函数也要遵循单一职责原则，即一个函数制作一件事情。如果发现一个函数里面有不同的任务，则需要将不同的任务以另一个函数的形式分离出去。
• 优点：如果类与方法的职责划分的很清晰，不但可以提高代码的可读性，更实际性地更降低了程序出错的风险，因为清晰的代码会让bug无处藏身，也有利于bug的追踪，也就是降低了程序的维护成本。

三、依赖倒置原则。

依赖抽象而不是依赖实现。抽象不应该依赖细节，细节应该依赖抽象。高层模块不能依赖低层模块，二者都应该依赖抽象。

• 解读：简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。其核心思想是：要面向接口编程，不要面向实现编程。
• 优点：通过抽象来搭建框架，建立类和类的关联，以减少类间的耦合性。而且以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。

四、接口分离原则。

多个特定的客户端接口要好于一个通用性的总接口。

• 解读：客户端不应该依赖它不需要实现的接口。不建立庞大臃肿的接口，应尽量细化接口，接口中的方法应尽量少。需要注意的是接口的力度也不能太小，如果过小，则会造成接口数量过多，使设计复杂化。接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
  • 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
  • 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
• 优点：避免同一个接口里面包含不同类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。

五、迪米特法则

一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象。

• 解读：迪米特法则也叫做最少知道原则，一个类应该只和它的成员变量，方法的输入，返回参数中的类作交流，而不应该引入其他的类（间接交流）。
• 优点：实践迪米特法则可以良好地降低类与类之间的耦合，减少类与类之间的关联程度，让类与类之间的协作更加直接。

六、里氏替换原则。

所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变。

• 解读：里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

• 优点：可以检验继承使用的正确性，约束继承在使用上的泛滥。