设计模式的几大原则

       网上很多分析设计原则的文章，有些大神写得非常好，有例子，有说明，深入浅出，本人此处只列出几个普遍通用的设计原则，讲一下我的理解，代码实现需读者自行验证。

总原则：开闭原则（Open Close Principle）

        开闭原则就是说:对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。

所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。

1、单一职责原则（Single responsibility principle）

        原理：不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

此处多说一句：对于方法定义也理应如此，一个方法只干一件事。

      违反后果： 

          a、当一个职责发生变化时,可能会影响其它的职责，多个职责耦合在一起，会影响复用性、 维护性、可扩展性。

          b、类的职责不清晰，不符合高内聚设计要求。

2、里氏替换原则（Liskov Substitution Principle）

        原理：里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

里氏替换原则的含义是：如果一个程序中所有使用基类的地方都可以用其子类来替换，而程序的行为没有发生变化，那么这个子类就遵守了里氏替换原则。换句话说，一个子类应该可以完全替代它的父类，并且保持程序的正确性和一致性。

里氏替换原则的目的是：为了保证继承关系的合理性和稳定性，避免出现继承层次混乱和子类过度扩展的情况

          违反后果： 

                a、降低代码的复用性和可维护性，提高了程序的耦合度和复杂度。

                b、子类改变了父类的行为，会导致程序出错。

3、依赖倒置原则（Dependence Inversion Principle）

        原理：开闭原则的基础，具体内容是面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

            违反后果： 

                a、导致代码耦合度过高。

                b、限制了代码的可扩展性。

                c、如果高层模块依赖于低层模块,那么这两个模块之间的耦合度将非常高,而且修改其中

                      一个模块可能会影响到另一个模块。

                扩允：引用一篇文章：2.3 依赖倒置原则 - 知乎 推荐阅读第2节什么要依赖倒置。

4、接口隔离原则（Interface Segregation Principle）

        原理： 这个原则的意思是每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个接口上）要好。

该原则很好理解，不要把不相关的功能接口揉在一起，代码可不像乱麻，可以快刀斩掉。

        违反后果： 

                a、接口定义模糊，代码混乱，可维护性差。

                b、长期违反者，可能会被其他同事吐嘈，严重时会丢了饭碗。

5、迪米特法则（最少知道原则）（Demeter Principle）

        原理：该法测是说一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

说明一下：

 该原则我发现在工作中很多同事都在犯，糊里糊涂地就犯了，我也不例外，主要原因有两点，一是在写代码的过程中需求方一天三催，充分表达了他们的责任心，时间紧迫，不管三七二十一，先完美犯错，二是开发者没有意识或经验不足，纵使前面是坑，也勇往直前。最后的后果就是出现重复代码，腐烂代码。

        违反后果：

                  a、代码重复度高，冗余，后期维护难。

6、合成复用原则（Composite Reuse Principle）

        原理： 原则是尽量首先使用合成/聚合的方式，（门面设计模式也是该思想）而不是使用继承。

        个人感觉是用接口还是继承，要看具体场景，要符合语义：

        接口语义表达：CAN-DO

        抽象类语义表达：IS-A

        违反后果：

                  a、过多使用继承，会使代码灵活性变差，当然合适的场景，还是推荐抽象类，选择更符合的方式来实现比较好。

7、奥卡姆剃刀原则

        原理：奥卡姆剃刀原理的核心是简单性原则，这是一种哲学思想，用到软件设计就是常说的：“如非必要，勿增实体”。

        建议读者在开发软件之前先想一想：

               1. 做这个设计有没有必要？

               2.设计这个东西目的是什么？

               3.带来什么价值？

               4.设计能不能再简单点？

               5.有没有更优更好的方案？

        灵魂拷问之下，答不上者，请慎重撸码。

        违反后果：

                  a、随着业务增长，不加思考就增加实体，系统设计就会在开发过程中变得非常复杂臃肿，读者想想，是不是有时接到一个旧系统时有一丝想重写它的冲动？

                  b、还有一个严重的问题，复杂度达到一定程度后，前期开发就会前功尽弃。无意给后来者创造一个重写系统的机会，浪费了人力和物力。

个人见解，如有不妥，请评论留言，共勉之。