设计模式的六大原则

一、单一职责原则

思想：一个方法只负责一件事情。
描述：一个类或者一个方法只负责一个职责，各个职责的程序改动，不影响其他程序。
优点：降低类和类的耦合，提高可读性，增加可维护性和可扩展性，降低可变性的风险。

二、里氏替换原则

思想：可以在任何使用基类的地方使用其子类，完美的替换基类。
描述：子类可以扩展父类的功能，但不能改变父类原有的功能；子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；子类中可以增加自己特有的方法。
优点：增加程序的健壮性，即使增加了子类，原有的子类还可以继续运行，互不影响。

三、依赖倒转原则

思想：高层次的模块不应该依赖于低层次的模块，它们都应该依赖于抽象；抽象不应该依赖于具体实现，具体实现应该依赖于抽象。、
描述：类A直接依赖于类B，假如要将类A改为直接依赖于类C，则必须通过修改类A的代码来完成。这种场景下，类A一般是高层次模块，负责复杂的业务逻辑，而类B和类C是低层次模块，负责基本的原子操作。假如修改类A，会给程序带来不必要的风险。
优点：可以减少需求变化带来的工作量，做并行开发更加友好。

四、接口隔离原则

思想：一个类对另一个类的依赖应该建立在最小的接口上。
描述：类A通过依赖于接口B，类C通过依赖于接口D，如果接口C和D不是最小接口，则依赖于它们的类A和B必须要实现它们不需要的方法。
优点：提高程序的灵活度，提高内聚，减少对外交互，使得最小的接口做最多的事情。

五、迪米特原则

思想：一个对象应当对其他对象有尽可能少的了解，简称类间解耦。
描述：一个类尽量减少自己对其它对象的依赖，原则是低耦合高内聚，只有使各个模块之间的耦合尽量地低，才能提高代码的复用率。
优点：低耦合高内聚。

六、开放封闭原则

思想：尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化。
描述：一个软件产品在生命周期中都会发生变化，既然变化是一个既定的事实，我们就应该在设计的时候尽量适应这些变化，以提高项目的稳定性和灵活性。
优点：单一原则要求每个类都有自己负责的职责；里氏替换原则不能破坏继承关系的体系。