关于设计模式:术篇设计模式-设计模式概述及其原则

设计模式代表了最佳的实际，通常被有教训的面向对象的软件开发人员所采纳。设计模式是软件开发人员在软件开发过程中面临的个别问题的解决方案。这些解决方案是泛滥软件开发人员通过相当长的一段时间的试验和谬误总结进去的。

设计模式次要是基于面向对象的以下准则：

共分为三大类

创立型模式 ，共五种：工厂办法模式、形象工厂模式、单例模式、建造者模式、原型模式。
结构型模式 ，共七种：适配器模式、装璜器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式 ，共十一种：策略模式、模板办法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

除以上三大类以外还有两类，即并发型模式和线程池模式。

对扩大凋谢，对批改关闭。在程序须要进行拓展的时候，不能去批改原有的代码，而是要扩大原有代码，实现一个热插拔的成果。即：为了使程序的扩展性好，易于保护和降级。

核心思想： 应该有且仅有一个起因引起类的变更
问题形容： 如果有类 Class1 实现职责 T1，T2，当职责 T1 或 T2 有变更须要批改时，有可能影响到该类的另外一个职责失常工作。
益处： 类的复杂度升高、可读性进步、可维护性进步、扩展性进步、升高了变更引起的危险。
需注意： 繁多职责准则提出了一个编写程序的规范，用“职责”或“变动起因”来掂量接口或类设计得是否低劣，然而“职责”和“变动起因”都是不能够度量的，因我的项目和环境而异。

核心思想 ：高层模块不应该依赖底层模块，二者都该依赖其形象；形象不应该依赖细节；细节应该依赖形象；
阐明：高层模块就是调用端，低层模块就是具体实现类。形象就是指接口或抽象类。细节就是实现类。
艰深来讲： 依赖倒置准则的实质就是通过形象（接口或抽象类）使个各类或模块的实现彼此独立，互不影响，实现模块间的松耦合。
问题形容： 类 A 间接依赖类 B，如果要将类 A 改为依赖类 C，则必须通过批改类 A 的代码来达成。这种场景下，类 A 个别是高层模块，负责简单的业务逻辑；类 B 和类 C 是低层模块，负责根本的原子操作；如果批改类 A，会给程序带来不必要的危险。
解决方案： 将类 A 批改为依赖接口 interface，类 B 和类 C 各自实现接口 interface，类 A 通过接口 interface 间接与类 B 或者类 C 产生分割，则会大大降低批改类 A 的几率。
益处：依赖倒置的益处在小型我的项目中很难体现进去。但在大中型我的项目中能够缩小需要变动引起的工作量。使并行开发更敌对。

核心思想 ：类间的依赖关系应该建设在最小的接口上
艰深来讲： 建设繁多接口，不要建设宏大臃肿的接口，尽量细化接口，接口中的办法尽量少。也就是说，咱们要为各个类建设专用的接口，而不要试图去建设一个很宏大的接口供所有依赖它的类去调用。
问题形容： 类 A 通过接口 interface 依赖类 B，类 C 通过接口 interface 依赖类 D，如果接口 interface 对于类 A 和类 B 来说不是最小接口，则类 B 和类 D 必须去实现他们不须要的办法。
需注意：
接口尽量小，然而要有限度 。对接口进行细化能够进步程序设计灵活性，然而如果过小，则会造成接口数量过多，使设计复杂化。所以肯定要适度
进步内聚，缩小对外交互 。使接口用起码的办法去实现最多的事件
为依赖接口的类定制服务 。只裸露给调用的类它须要的办法，它不须要的办法则暗藏起来。只有专一地为一个模块提供定制服务，能力建设最小的依赖关系。

核心思想： 类间解耦。
艰深来讲： 一个类对本人依赖的类晓得的越少越好。自从咱们接触编程开始，就晓得了软件编程的总的准则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，能力进步代码的复用率。低耦合的长处显而易见，然而怎么样编程能力做到低耦合呢？那正是迪米特法令要去实现的。