23种设计模式

适配 即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。 例如：二转换为三箱插头，将高电压转换为低电压等。 动机(Motivate): 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。 那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的 Adapter 模式。 意图(Intent): 将一个类的接口转换成客户希望的另外一个接口。 Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 -------《设计模式》GOF 抽象的 UML 类图 　　4 种角色：Adaptee（被适配），Adapter（适配者），Client（使用场景），Target（目标对象）。 　　Adaptee（被适配）：不是 -er 结尾的哦，之前的 Portal（入口）类作为被适配者。 　　Adapter（适配者）：作为 Adaptee 和 Target 的媒介，进行调节。 　　Client（使用场景）：一个调用的入口，以 Main() 作为入口函数。 　　Target（目标对象）：调节（适配）后的输出，之前的 IOutput 接口和 Export 类都是作为 Target 对象。 图：类适配器（使用继承） 图：对象适配器

单例 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例（eg：应对一些特殊情况，比如数据库连接池(内置了资源) 全局唯一号码生成器），才能确保它们的逻辑正确性、以及良好的效率。 优点：单例的好处就是单例，就是全局唯一的一个实例 单例模式会阻止其他对象实例化其自己的单例对象的副本，从而确保所有对象都访问唯一实例 缺点：单例可以避免重复创建，但是也会常驻内存 除非是真的有必要，否则不要单例 使用单例对象（尤其在类库中定义的对象）时，开发人员必须记住自己不能使用new关键字实例化对象。因为可能无法访问库源代码，因此应用程序开发人员可能会意外发现自己无法直接实例化此类 如何绕过常规的构造器，提供一种机制来保证一个类只创建一个实例？ 如何实现？将构造函数私有化，然后对外提供一个公开的静态方法，使用一个静态属性进行判断当前对象是否被创建 1 // 不要用这种方式 2 public class Singleton 3 { 4 private static Singleton _instance = null; 5 private Singleton() { } 6 public static Singleton CreateInstance() 7 { 8 if (_instance == null) 9 { 10 _instance = new Singleton();

定义： 定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。 类型： 行为类模式 类图： 在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署的功能，就像eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。这两个功能有一个相似的地方，那就是一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相应的行动。其实，能够实现这一点的方案很多，但是，无疑使用观察者模式是一个主流的选择。 观察者模式的结构 在最基础的观察者模式中，包括以下四个角色： 被观察者： 从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用

访问者模式的定义 定义: 封装一些作用于某种数据结构中的各元素的操作, 它可以在不改变数据结构的前提下定义作用于这些元素的新的操作 通俗的说, 就是定义一个访问者角色, 当对指定角色进行访问时要通过访问者进行访问 其类图如下: 各角色说明: Vistor 抽象访问者: 抽象类或接口, 声明访问者可以访问哪些元素, 具体到程序中就是 visit 方法的参数定义哪些对象是可以被访问的 ConcreteVistor 具体访问者: 它影响访问者访问到一个类后该怎么干, 要做什么事 Element 抽象元素: 接口或抽象类, 声明接受哪一类访问者访问, 程序上是通过 accept 方法中的参数来定义的 ConcreteElement 具体元素: 实现 accept方法, 通常是 visitor.visit(this); 基本上都形成一种模式了 ObjectStruture 结构对象: 元素的生成者, 一般容纳在多个不同类、不同接口的容器, 项目中一般很少抽象出这个角色 抽象元素代码: 具体元素代码: 抽象访问者代码: 具体访问者代码: 结构对象用来产生不同的元素对象, 代码如下: 场景类代码: 通过增加访问者, 这要是具体元素就非常容易访问, 对元素的遍历就更加容易了, 甭管它是什么对象, 只要它在一个容器中, 都可以通过访问者来访问, 任务集中化. 访问者模式的应用 访问者模式的优点:

目录 创建型 1. Factory Method （工厂方法） 2. Abstract Factory （抽象工厂） 3. Builder （建造者） 4. Prototype （原型） 5. Singleton （单例） 结构型 6. Adapter Class/Object （适配器） 7. Bridge （桥接） 8. Composite （组合） 9. Decorator （装饰） 10. Facade （外观） 11. Flyweight （享元） 12. Proxy （代理） 行为型 13. Interpreter （解释器） 14. Template Method （模板方法） 15. Chain of Responsibility （责任链） 16. Command （命令） 17. Iterator （迭代器） 18. Mediator （中介者） 19. Memento （备忘录） 20. Observer （观察者） 21. State （状态） 22. Strategy （策略） 23. Visitor （访问者） 创建型 1. Factory Method （工厂方法） 意图： 定义一个用于创建对象的接口，让子类决定实例化哪一个类。 Factory Method 使 一 个类的实例化延迟到其子类。 适用性： 当一个类不知道它所必须创建的对象的类的时候。

设计模式（Design Patterns） 　　首先说一下我对设计模式的理解，设计模式是一种在软件内部优化代码的技巧。注意，是代码的内部，也就是在一个局部范围内优化设计。这一点和软件的架构是完全不同的，软件架构是全局的优化，讲的是怎么对软件进行切分以及对切开之后的内容进行重组的一个过程。软件的设计模式强调的是代码，软件架构强调的是结构。在面向对象的编程思想中，这就体现在怎么解决类与类之间的关系。能处理好类与类之间的关系，优化设计就搞好了。下面这段话是软件设计模式的定义： 　　设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 　　 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。设计模式是一代又一代的编程大师总结出来的，我们应该重视，不能束之高阁，应当合理利用。关键是要搞清楚哪种情况用哪种设计模式。 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式

原文链接: http://blog.csdn.net/zhangerqing 一、设计模式的分类 总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 总原则：开闭原则（Open Close Principle） 开闭原则就是说 对扩展开放，对修改关闭 。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。 1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 2、里氏替换原则（Liskov Substitution Principle） 里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互

设计模式的六大设计原则 开闭原则（O） ：对扩展开放，对修改关闭。开闭原则是总原则，指尽量高度抽象，易扩展。 单一原则（S） ：一个类的接口抽象一个职责。 里氏替换原测（L） ：里氏替换是对开闭原则的补充，开闭原则为接口抽象，里氏替换则为接口的具体实现。 依赖倒置原则（D） ：面向接口编程，不跟具体实现类交互，跟接口交互。 接口隔离原则（I） ：每个接口的实现类必须是完全实现，如果说子类中存在不需要实现的方法，那么接口应该把这个方法拆分出去。 迪米特法则（D） ：一个类对自己的依赖应该是知道的越少越好，只需要关注调用的public方法。 23种Java设计模式 来源： https://blog.csdn.net/weixin_39506910/article/details/99451389

定义： 确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。 类型： 创建类模式 类图： 类图知识点： 1.类图分为三部分，依次是类名、属性、方法 2.以<<开头和以>>结尾的为注释信息 3.修饰符+代表public，-代表private，#代表protected，什么都没有代表包可见。 4.带下划线的属性或方法代表是静态的。 5.对类图中对象的关系不熟悉的朋友可以参考文章： 设计模式中类的关系 。 单例模式应该是23种设计模式中最简单的一种模式了。它有以下几个要素： 私有的构造方法 指向自己实例的私有静态引用 以自己实例为返回值的静态的公有的方法 单例模式根据实例化对象时机的不同分为两种：一种是饿汉式单例，一种是懒汉式单例。饿汉式单例在单例类被加载时候，就实例化一个对象交给自己的引用；而懒汉式在调用取得实例方法的时候才会实例化对象。代码如下： 饿汉式单例 1 2 3 4 5 6 7 public class Singleton { private static Singleton singleton = new Singleton ( ) ; private Singleton ( ) { } public static Singleton getInstance ( ) { return singleton ; } } 懒汉式单例 1 2 3 4 5 6 7 8 9

定义： 为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。 类型： 创建类模式 类图： 抽象工厂模式与工厂方法模式的区别 抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。 在抽象工厂模式中，有一个 产品族 的概念：所谓的产品族，是指 位于不同产品等级结构中功能相关联的产品组成的家族 。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。 在上面的类图中，两厢车和三厢车称为两个不同的等级结构；而2.0排量车和2.4排量车则称为两个不同的产品族。再具体一点，2.0排量两厢车和2.4排量两厢车属于同一个等级结构，2.0排量三厢车和2.4排量三厢车属于另一个等级结构；而2.0排量两厢车和2.0排量三厢车属于同一个产品族，2.4排量两厢车和2.4排量三厢车属于另一个产品族。 明白了等级结构和产品族的概念，就理解工厂方法模式和抽象工厂模式的区别了