weixin_46073538的博客

享元模式(Flyweight Pattern) 也叫 蝇量模式:运用共享技术有效地支持大量细粒度的对象常用于系统底层开发，解决系统的性能问题。像数据库连接池，里面都是创建好的连接对象，在这些连接对象中有我们需要的则直接拿来用，避免重新创建，如果没有我们需要的，则创建一个享元模式能够解决重复对象的内存浪费的问题，当系统中有大量相似对象，需要缓冲池时。不需总是创建新对象，可以从缓冲池里拿。

外观模式(Facade)，也叫“过程模式:外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用外观模式通过定义一个一致的接口，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节外观模式对外屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复杂性外观模式对客户端与子系统的耦合关系-解耦，让子系统内部的模块更易维护和扩展通过合理的使用外观模式，可以帮我们更好的划分访问的层次。

对于这个图片肯定会非常熟悉，上图我们可以看做是一个文件系统，对于这样的结构我们称之为树形结构。在树形结构中可以通过调用某个方法来遍历整个树，当我们找到某个叶子节点后，就可以对叶子节点进行相关的操作。可以将这颗树理解成一个大的容器，容器里面包含很多的成员对象，这些成员对象即可是容器对象也可以是叶子对象。但是由于容器对象和叶子对象在功能上面的区别，使得我们在使用的过程中必须要区分容器对象和叶子对象，但是这样就会给客户带来不必要的麻烦，作为客户而已，它始终希望能够一致的对待容器对象和叶子对象。

装饰者模式:动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)这里提到的动态的将新功能附加到对象和 ocp 原则。

现在有一个需求，需要创建不同的图形，并且每个图形都有可能会有不同的颜色。我们可以利用继承的方式来设计类的关系：我们可以发现有很多的类，假如我们再增加一个形状或再增加一种颜色，就需要创建更多的类。试想，在一个有多种可能会变化的维度的系统中，用继承方式会造成类爆炸，扩展起来不灵活。每次在一个维度上新增一个具体实现都要增加多个子类。为了更加灵活的设计系统，我们此时可以考虑使用桥接模式。定义：将抽象与实现分离，使它们可以独立变化。

适配器模式(Adapter Pattem)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)适配器模式属于结构型模式主要分为三类:类适配器模式、对象适配器模式、接口适配器模式基本介绍:Adapter类，通过继承 src 类，实现dst 类接口，完成src->dst 的适配。

建造者模式(Builder Pattern)又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别)，使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。建造者模式 是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们.用户不需要知道内部的具体构建细节。

原型模式(Prototype 模式)是指:用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节工作原理是:通过将一个原型对象传给那个要发动创建的对象,这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建，即 对象.clone()形象的理解:孙大圣拔出猴毛，变出其它孙大圣用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型对象相同的新对象。

优点是比较好理解，简单易操作。缺点是违反了设计模式的 ocp 原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码比如我们这时要新增加一个新的实现类，需要修改源代码现有3个类，分别是Coffee、AmericanCoffee、LatteCoffeeCoffee类System.out.println("Coffee加糖");System.out.println("Coffee加奶");@Override。

单例模式保证了 系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用 new单例模式使用的场景:需要频繁的进行创建和销毁的对象、创建对象时耗时过多或耗费资源过多(即:重量级对象)，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象(比如数据源、session 工厂等)