设计模式[六大原则]

写到设计模式，还是得先聊聊软件设计六大原则，上乘经文，多读益善；

在软件生命周期中，良好的架构设计对于后期开发维护起着举足轻重的作用，一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分。

单一职责原则（Single Responsibility Principle）

强调一个类，或者一个接口，只负责一件事情，当发生变化时，只能受到单一的影响；因为职责过多，可能引起变化的原因将会很多，这样导致职责和功能上的依赖，将严重影响其内聚性和耦合度，混乱由此而生，所谓剪不断理还乱；
解决的办法就是拆分职责，细化功能粒度，使其各司其职，也就是提高模块内聚性，降低模块间耦合性；
单一职责，深入透彻oo的类的封装性，使得降低维护复杂性，提高扩展性，同时也使代码更加清晰明了；

里氏替换原则（Liskov Substitution Principle）

主张使用“抽象”和“多态”将设计中的静态结构改为动态结构，既维持了设计的封闭性，又提高基类职责的扩展性；对类中的接口类型和公共实现做到很好的复用，相关的设计模式可参考工厂方法模式，策略模式，模板方法模式等；

依赖倒置原则（Dependence Inversion Principle）

依赖倒置原则，重要的三层含义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。其核心思想是：依赖于抽象。
相对LSP的自身抽象和多态，DIP更是强调模块间的依赖关系，主要就是面向接口和抽象的概念；

接口隔离原则（Interface Segregation Principle）

接口隔离，即一个类对另一个类的依赖应该建立在最小的接口上， 建立单一接口，而不是依赖一个拥有庞大臃肿接口的“大锅类”，尽量细化接口，接口中的方法尽量少。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
与单一职责同中有异，接口隔离强调一个类关联依赖的接口粒度化，而后者是类自身接口和实现均受外界单一影响这个规范。

迪米特法则（Law Of Demeter）

一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

开闭原则（Open Closed Principle）

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
研发一个Base项目，不仅考虑以上方面，对于商业来说，高效，快捷，优质的完成相关的定制增项项目，是很重要的，直接影响到公司的成本问题。这里就是开闭原则的重要性，修改关闭，要求定制任务不会修改原始代码，保证了原始单元和系统稳定性，扩展开放，支持扩展新的功能，而不影响原有的黑匣子；

上面的内容，摘自网络和自己的一些理解，没有举例作图，后续有时间再进行补充。