设计模式的六大原则

首先说说什么叫设计模式：

      就是面向对象语言开发过程中，遇到的种种场景问题，提出的解决方案和思路，沉淀下来的解决具体问题的解决方案。

而设计模式的六大原则则是：

面向对象开发语言开发过程中，一些推荐的指导性原则。（也就是前辈总结出来经验的结晶）

没有明确的招数，而且经常会被忽略/违背。

• 单一职责原则SRP：封装的深度

优点：一个类只负责一件事，只做一件事，将复杂的业务拆分成简单的，简单表示强大且稳定，且容易维护。

缺点：但是也会产生一些成本，代码量增加了，类多了，使用的成本也变高了（理解的成本）。

变量的单一原则：一个变量只使用一次（第二次使用表示用于别业务）。

属性/字段单一原则：一个属性或字段只做一件事，使用一次。

方法的单一原则：将方法拆分出去，只负责属于自己的业务。

类的单一原则：一个类只做一件事，负责一个实现。

类库的单一原则：类库的职责明细清晰。

项目的单一原则：一个项目只负责一个业务，如：后台管理、客户端、数据访问等等..

系统的单一原则：将通用的功能拆分成系统，如：管理日志、前台、后台

一些建议：

如果类型的业务足够简单，方法属性足够少，可以适当的违反单一原则。（但不太建议）

如果类型的业务复杂，分支复杂，多使用单一职责。（多使用抽象、多态）

• 里氏替换原则LSP：子类替换基类

任何基类出现的地方，都可以使用子类来替换。

继承+透明：透明是指子类替换成基类之后只能使用基类的成员，如果子类有重写基类的行为程序执行的时候则会调用子类的方法（虚方法、抽象方法）。

优点：可以灵活扩展，实现多态。

缺点：使用继承，类和类之间关系过于依赖，如果基类产生波动会直接影响到子类。

还有一些问题：

1. 基类的成员子类必须有，如果基类中有子类没有的成员，应断掉继承。再来一个基类，只包含应有的成员。

2. 子类可以使用基类的公有属性和行为，但是替换成基类之后则不能使用子类的额外的行为和属性。

3. 基类实现的东西，子类不要再写了（普通方法），尽量不要使用New来隐藏父类的行为。

    如果需要修改，请使用abstract或virtual声明行为。

一些建议：

声明通用属性，字段，变量，尽量声明在基类中，因为父类比较灵活（多态）。

• 迪米特原则LOD：不要和陌生人说话

一个对象应该只对其它对象保持最少的联系，只与直接的朋友联系。(例如：学生应该和班级关联，学生对象不应出现在学校对象业务)

类和类之间的关系：

纵向：继承==实现（依赖最为密切）

横向：聚合>组合>关联>依赖（出现在类的内部，叫做依赖，方法参数不算）

而迪米特原则，则是将这些关系弱化，只跟自己的朋友通话（联系），非间接的则留给他人关联。

优点：类和类之间的依赖减少了，耦合度降低了

缺点：

也产生了一写耦合，违反了高内聚低耦合的思想，但是有时候是无法避免的。

也会产生一些成本（理解成本）。

一些建议：

多使用适当的修饰符，修饰元素：

private 私有的
protected //子类
internal 类库的内部
protected internal 子类或类库的内部

• 依赖倒置原则DIP：面向抽象编程

高层不依赖底层，而依赖于抽象，其实就是说面向抽象编程。

依赖抽象编程，而不是面向细节编程：

抽象：接口/抽象类，可以包含一些没有确定的东西，没确定的东西可以千变万化..

细节：普通类，一些都是已经确定的。（不支持动态扩展）

抽象的好处：

一个方法可以满足不同类型的参数，业务。

支持灵活扩展，只需要实现了这个抽象。

缺点：成本增加（这个可以忽略）。

一些说法：

面向对象语言开发，就是类与类之间进行交互。

面向细节：如果高层依赖底层细节，细节是多变的，如果层级多了，底层修改会直接波动到高层，一点细微的改动导致整个系统上上下下都需改动（加班），且不支持灵活扩展。

面向抽象：如果高层和底层没有直接依赖，而是依赖于抽象，抽象相对来说是比较稳定，那么底层修改扩展就不会直接影响到高层。这样内部还支持层内横向扩展，不会影响到其它地方，这样的程序架构相对来说是稳定的。

• 接口隔离原则ISP：接口最小化

ISP 就是将接口最小化（按最小功能分类定义接口，如果需要功能集合可以接口继承接口）

和单一原则差不多，都是为了职责单一，职责清晰。

优点：职责清晰

缺点：成本增加（忽略）。

需要注意的问题：

1. 不要定义大而全的接口，这样抽象意义就不大了。

2. 也不能一个方法一个接口，按照功能密不可分定义接口。

3. 随着业务发展接口也会产生变化的，设计时需要留好扩展，提前做好准备。

4. 接口合并，尽量内聚，接口不需要暴露太多。

• 开闭原则OCP：扩展开放，修改关闭

开放：以增加类的方式进行业务扩展

关闭：修改原有的代码

面向对象是是静态语言，一旦发生改动会波及很多东西，就需要进行全面的测试。

而我们最理想的状态就是通过增加类对业务扩展，对原有的代码没有改动，原有的代码是可信的。

这是我们追求的目标，并没有任何的手段，也被称之为终极原则。

其它的五个原则建议，只是为了更好的OCP。

一些建议：

修改现有的方法->增加方法->增加类->增加/替换类库

• 总结：

设计原则，都是前辈的结晶，只是用来做参考/建议，非一定要遵守。
实际项目中很难全部遵循，更多的时候回有一些侧重，设计一个功能的多一丝思考。