设计模式六大原则

一 概述

设计模式是什么：
1、是对整个软件系统的拆分，组装，并决定模块间关系以及如何互动、通信的某种模式；
2、其本质是以语言特性 面向对象三大特性 为出发点，通过设计模式六大原则总结出来的套路；

二 六大原则

单一职责

• 概念：功能完备的软件系统是复杂的，系统的拆分与模块化是不可或缺的，而面向对象是以类来划分模块边界的（一对大括号“{}”定义了类模块的边界），也就是说每个类都代表着一个功能角色模块，其职责应该是单一的，不是自己分内的事不应该负责；
• 单一职责原则规定，对任何类的修改只能有一个原因；例如一个灯泡类，它的职责就是照明，与其无关的一切修改动机都不予考虑，因此灯泡不能封装与其本身职责不相干的功能，这样就保证其职责的单一性原则；
• 类与类之间有明确的职责划分，同时也保持一种协作的、分与合/对立与统一的辩证关系；例如责任链模式中环环相扣审批人的职责范围就是很好的例子，各顾各的、不管闲事；职责的单一性保证了类的高内聚、低耦合，如此便提高了代码的易读性、易维护性、易测试性、易复用性；

开闭原则

• 概念：“开”表示对扩展开放，”闭“表示对修改关闭；通俗来讲就是不要修改已有的代码，而是去写新的代码；在一个稳定运行的系统中，修改原有的代码需要较大的成本，例如充分的场景测试等，否则一个小小的修改就有可能会造成整个系统瘫痪；
• 开闭原则通过抽象来实现，高层的泛化保证了底现的多态化扩展；
• 例如访问者模式：随着需求的变化，不应该修改原有的资源，而是通过新的访问者模块、新的资源模块去实现这些新增的功能，系统一旦确立就不可再修改现有代码，这便是对扩展的开放，对修改的关闭，添加是比修改好的；若系统迭代需要修改大量代码，则说明这个设计是失败的，是违反开闭原则的；开闭原则中对抽象的大量运用奠定了系统的可复用性、可扩展性的基石，增加了系统的稳定性；

里氏替换

• 概念：指父与子之间的可替换性：任何父类出现的地方子类一定也可以出现，也就是说一个优秀的设计中，有引用父类的地方，一定可以用其子类进行替换，这完美切合了面向对象设计语言中 继承与多态 的特性；在相关框架的编程过程中，需要有 面向抽象编程 的思想，而不是深入到具体子类中，这样才能保证子类多态的可能性；
• 例如策略模式：电脑需要依赖抽象USB接口去读取数据，至于具体接入什么设备电脑是不必关心的，只要是兼容USB接口的设备即可，这就实现了多种USB设备的里氏替换，让系统功能模块可灵活替换，可向外延伸扩展；

接口隔离

• 概念：指对高层接口的独立、分化，客户端对类的依赖应该基于 最小接口，而不应该依赖不必要的接口；简单来说即定义接口时尽量往小定义，比如一个接口只对应一个角色职能；
• 接口隔离原则要求对接口尽可能地细粒度化，小接口总比大接口要好；
• 接口隔离原则与单一职责原则类似，都是对高层行为能力的细粒度化规范：分开永远比合起来容易；
• 接口隔离原能很好地避免接口被设计地过于臃肿，轻量化接口更不会造成对实现类的污染，使系统模块间依赖变得更加松散、灵活；

依赖倒置

• 概念：通过只依赖抽象而不依赖具体实现，从而达到降低客户端对其他模块耦合的目的；客户端类要访问另一个类时，传统做法是直接访问其方法，这就导致了对实现类的强耦合；而依赖倒置的做法是反其道而行，间接地访问实现类的高层抽象，依赖高层比依赖底层实现要灵活得多（也就是里式替换中的 面向抽象编程）；
• 依赖倒置通过依赖抽象，使得组件之间可以灵活调用，万事万物相互组合；
• 采用 面向抽象编程 的思想，从高层往底层写代码，比如在业务逻辑中，不必关心数据源是什么，只需要编写一个数据访问接口，暂且不进行实现；只要是定义了良好的接口规范就不必关心底层实现细节，依赖高层抽象，不依赖底层具象，这便是依赖倒置原则的核心思想，从具象到抽象的倒置；

迪米特法则

• 概念：也被称为最少知识原则，主要是通过最小化各模块间的通信，来割裂模块间千丝万缕的不必要联系，以达到松耦合的目的；迪米特法则提出，一个模块对其他模块要知之甚少、拒绝陌生人、只和熟人交谈，否则对一个类的变动将引发蝴蝶效应般的连锁反应，这会波及到大范围的变动，系统可维护性差；
• 比如在一台游戏机中，其内部集成了复杂的电路以及各种电子元件，其通过对外开放手柄控制接口来达到控制的目的，对用户来说只需要用手柄操作就可以了，至于其内部的那些磁盘载入、内存读取、CPU指令接收、显卡显示等等是完全陌生的，也并不会去直接调用，这就是用户的正确使用方法；
• 例如门面模式：系统模块应该隐藏内部机制，对外只暴露适度地接口，这样才能保证模块间的最少知识通信，切勿越级汇报，禁止跨界、干涉他人内务，让模块间调用变得”傻瓜化“，即开即用，使模块间降低耦合性，提高软件系统的可维护性、可扩展性；

三 总结

• 设计模式也是对代码使用的抽象，其之间可以相互组合使用，如同方法论一样，万事万物均可抽象组合，最大元素也是最小元素；
• 设计模式不可滥用，有时本来几个类就可以解决的的需求，没有必要拆成几十个角色类，这反而会适得其反，很简单的一个系统搞得臃肿不堪；需求虽然是多变的，但一个系统不可能不做修改就满足所有变化，需根据当下以及可以预估的未来变更运用恰当的模式，适可而止，以不变应万变才不至于过度设计，模式泛滥；
• 最终，对设计模式的思想真谛来说，设计模式的名字已经不重要，在实际应用中能快速解决当下问题才是最务实的工作态度；某个时刻也许用到了某个模式的变种，又或是几个设计模式之间的组合运用，这都并没有一个确切的名字，或者是确切的哪一个设计模式，达到得心应手、挥洒自如的境界；

源码地址：我的GitHub