六大设计原则

一、单一职责原则

    1.定义：应该有且仅有一个原因引起类的变更。

    2.单一职责的好处

        a.类的复制性降低，实现什么职责都有清晰明确的定义

        b.可读性提高，复杂性降低，那当然可读性提高了

        c.可维护性的提高，可读性提高，当然更容易维护

        d.变更引起的风险降低，本身变更是必不可少的，接口的单一职责做的好，一个接口修改只针对响应的实现类有影响，对其他接口无影响，对系统的扩展性和维护性都有非常大的帮助

    3.总结：现实中想要全部按照单一职责原则很难在项目中得到提现，需要考虑的问题比较多，环境、工作量、人员技术水平以及资源等等；对于接口再设计的时候一定要做到单一；而对于实现类就需要多方面考虑；生搬硬套单一职责原则会引起类的剧增，反而给维护带来非常多的麻烦；俗话说原则是死的人是活的；具体问题还需据对应对

    4.结合我们酷客多产品接口设计案列，非常明显可以体验出单一职责的好处

        例如：酷客多小程序产品详情页面，相对将页面价格信息和促销信息数据的获取独立成两个单独接口；酷客多营销插件的更新迭代是比较频繁，不时新增一种营销插件；而将促销信息接口独立出后，后续无论增加多少种插件，也只需要调整促销信息接口即可，对应商品详情其他数据接口无需任何改动。

二、里氏替换原则

    1.定义：

        a.如果对每一个类型为S的对象01，都有类型为T的对象02，使得以T定义的所有程序P在所有的对象01都带换成02时，程序P的行为没有发生变化，那么类型S是类型T的子类型

        b.所有引用基类的地方必须能透明地使用其子类的对象；通俗的说，就是所有能使用父类的地方都可以替换为子类，不会产生任何错误或异常，但是反过来就不行了，有子类出现的地方，父类未必就能适应

    2.规范:

        a.子类必须完全实现父类的方法

            i.做系统设计时，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传入接口或抽象类，这里就是使用了里氏替换原则

            ii.在类种调用其它类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则

            iii.如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开负责继承关系，采用依赖、聚集、组合等关系代替继承

        b.子类可以有自己的个性,子类同时也可以有属于自己的属性和方法

        c.覆盖或实现父类的方法时输入参数可以被放大

        d.覆写或实现父类的方法时输出结果可以被缩小

三、依赖倒置原则

    1.定义：

        a.高层模块不应该依赖底层模块，两则都应该依赖其抽象

        b.抽象不应该依赖细节

            i.什么是抽象:抽象就是指接口或抽象类，两者都是不能直接被实例化的

            ii.什么是细节:细节就是实现类，实现接口或继承抽象类而产生的类就是细节，特点就是可以直接实例化，也就是new产生一个对象

        c.细节应该依赖抽象

    2.作用：依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性

    3.依赖的三种写法

        a.构造函数传递依赖对象

        b.Setter方法传递依赖对象

        c.接口声明传递依赖对象

四、接口隔离原则

    1.定义:

        a.客户端不应该依赖它不需要的接口。依赖是什么？依赖它需要的接口，客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，对接口进行细化，保证接口的纯洁性

        b.类间的依赖关系应该建立在最小的接口上。最小的接口也是需要细化的，接口的纯洁性如上，只是一个实物的两种不同的描述

    2.接口隔离原则的四层含义

        a.接口要尽量小

        b.接口要高内聚

        c.定制服务

        d.接口设计是有限度的

    3.总结：

        a.一个接口只服务于一个子模块或业务逻辑

        b.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

        c.已经污染了的接口，尽量去修改，若变更的风险比较大，则采用适配器模式进行转化处理。适配器模式可以单独查阅设计模式一书中相关信息

        d.了解环境，拒绝盲从。每个项目或产品都有特定的化境因素，别看到大师是这样做的你就照抄；环境不同，接口拆分的标准就不同。

五、迪米特法则

    1.定义：迪米特法则也称为最小知识原则，描述的规则：一个对象应该对其他对象有最少的了解，通俗的说，一个类应该对自己需要耦合或调用的类知道的最少，你的内部是如何复杂和我没关系，我就知道你提供的这么公开方法，我就调用这么多，其他一概不关心

    2.迪米特法则对类的低耦合提出了明确要求，其包含3层含义

        a.只和朋友交流。两个对象之间的耦合就成为朋友关系，这种关系的类型有很多，例如组合、聚合‘依赖等

        b.朋友间也是有距离的。一个类公开的属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大，因此为了保持距离，设计时需要反复衡量减少public方法和属性。

        c.是自己的就是自己的：如果一个方法放在奔雷中，既不增加类间关系，对本类不产生负面影响，那就放置在本类中

    3.总结：迪米特法则的核心观念就类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，而这样的要求结果回产生大量的中转和跳转类，导致系统的复杂性提供，同时也为维护带来了难度。因此，在实际项目中，需要适度地考虑这个原则，别为了套用原则而做项目。视情况而定。

六、开闭原则

1.定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

  扩展开放：意思是指当我们针对一个需求有变化时，我们通过扩展来实现变化，，这样对系统的最小化开发，修改也少，风险也小

  修改关闭：关闭修改应该变化，这样极大降低系统的风险，保持历史代码的纯洁性，提高系统的稳定性。

    2.好处

        a.开闭原则可以提供复用性

        b.开闭原则可以提供可维护性

    3.总结：开闭原则是一个非常虚地原则，前面5个原则是对开闭原则地具体解释，但是开闭原则并不局限这么多，它“虚”得没有边界，就像“好好学习，天天向上”得口号一样，告诉我们要好好学习，但是学什么，怎么学没有告诉我们，需要我们去体会和掌握，开闭原则也是一样。

六大设计原则总结

六大设计原则得核心其实是开闭原则，开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。因此，针对开闭原则的实现方法，一直都有面向对象设计的大师费尽心机，研究开闭原则的实现方式。而对于其他五大设计原则，都可以看作是开闭原则的实现方法。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：酷客多小程序 刘慈