设计模式 --- 六大原则

开闭原则

含义：对扩展开闭，对修改关闭。在设计程序的时候，面对需求的改变尽肯能的保持相对的稳定，尽量通过扩展的方式来修改原有代码来实现。可以通过“抽象约束、封装变化”来实现开闭原则，即通过抽象类或者接口定义一个稳定的抽象层，而将相同的可变因素封装在具体的实现类中。当需要发生改变的时候，只需要根据需求重新派生一个实现类进行扩展就好了。

里式替换原则

基本内容：继承必须确保超类所拥有的性质在子类中仍然成立。主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承。通俗的来讲：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说，子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。如果重写父类的方法来实现新的功能，那么会导致继承的可复用性变差。如果程序违背了里式替换原则，取消原来的继承关系，重新设计它们的继承关系。比如鸟类具备飞行的功能，但是企鹅，鸵鸟等鸟类并不会飞行，所以从类的继承关系上来设计，它们没有飞行的方法，所以它们并不能继承鸟类。但是我们可以将设计一个父类动物类，让企鹅和鸵鸟去继承动物类。

依赖倒转原则

核心思想：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。也就是面向接口编程，不要面向实现编程。在程序的设计与实现的时候，具体的实现类在不同的场景下细节不同，但是抽象层则相对稳定，具体的细节可以交给具体的实现类去处理。

参考链接：https://blog.csdn.net/zhengzhb/article/details/7289269

单一职责原则

规定了一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。如果一个类负责的功能过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。比如语文老师只负责教语文，数学老师只负责教数学，不应该一个老师负责多门课程的教授。

接口隔离原则

尽量将臃肿庞大的接口拆分成更小的和更具体的接口，尽量细化接口，接口中的方法尽量少，也就是我们要 为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用。但是拆分的同时，防止过于细化，负责会导致接口数量过多。

迪米特原则

一个软件实体应当尽可能少地与其他实体发生相互作用。如果两个类不彼此通信，那么这两个类就不应当直接地发生相互作用。如果其中一个类需要另一个类的某一个方法的话，可以通过第三者转发这个调用。迪米特法则的做法观念就是类间解耦，弱耦合，但是会产生了大量的中间类，导致的复杂性提高，同时也为维护带来了难度。