JAVA设计模式总结

最新推荐文章于 2025-06-25 18:24:17 发布

原创最新推荐文章于 2025-06-25 18:24:17 发布 · 400 阅读

CC 4.0 BY-SA版权

本文详细介绍了JAVA设计模式的分类，包括创建型、结构型和行为型模式，阐述了设计模式的六大原则，如开闭原则、里氏代换原则等。文章通过实例详细解析了工厂模式的三种形式，如简单工厂、工厂方法和静态工厂方法，以及单例模式、抽象工厂模式、建造者模式、原型模式等创建型模式。此外，还探讨了结构型模式，如适配器模式、装饰器模式、代理模式等，并简述了关系模式，如策略模式、观察者模式等。文章内容丰富，深入浅出，旨在帮助读者理解和掌握JAVA设计模式的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、设计模式的分类

总体来说设计模式分为三大类：

创建型模式（5种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式）
2.结构型模式（7种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式）
行为型模式（11种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式）

二、设计模式的六大原则

开闭原则（Open Close Principle）
里氏代换原则（Liskov Substitution Principle）
依赖倒转原则（Dependence Inversion Principle）
接口隔离原则（Interface Segregation Principle）
迪米特法则（最少知道原则）（Demeter Principle）
合成复用原则（Composite Reuse Principle）

开闭原则：就是说对扩展开放（提供方），对修改关闭（使用方）。在程序需要进行拓展的时候，尽量不能去修改原有的代码（因为这样可能导致使用方出现异常或者需要修改），实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

里氏代换原则：面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

依赖倒转原则：这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。

接口隔离原则：这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

迪米特法则：为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

合成复用原则：原则是尽量使用合成/聚合的方式，而不是使用继承。

三、创建型模式

首先，简单工厂模式不属于23中涉及模式，简单工厂一般分为：普通简单工厂、多方法简单工厂、静态方法简单工厂。

0、简单工厂模式

简单工厂模式模式分为三种：

01、普通

就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。首先看下关系图：

举例如下：（我们举一个发送邮件和短信的例子）

首先，创建二者的共同接口：

public interface Sender {  
    public void Send();  
}

其次，创建实现类：

public class MailSender implements Sender {  
    @Override  
    public void Send() {  
        System.out.println("this is mailsender!");  
    }  
}

public class SmsSender implements Sender {  
  
    @Override  
    public void Send() {  
        System.out.println("this is sms sender!");  
    }  
}

最后，建工厂类：

public class SendFactory {  
  
    public Sender produce(String type) {  
        if ("mail".equals(type)) {  
            return new MailSender();  
        } else if ("sms".equals(type)) {  
            return new SmsSender();  
        } else {  
            System.out.println("请输入正确的类型!");  
            return null;  
        }  
    }  
}

我们来测试下：

public class FactoryTest {  
  
    public static void main(String[] args) {  
        SendFactory factory = new SendFactory();  
        Sender sender = factory.produce("sms");  
        sender.Send();  
    }  
}

输出：this is sms sender!

02、多个方法

是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。关系图：

将上面的代码做下修改，改动下SendFactory类就行，如下：

public class SendFactory {  

   public Sender produceMail(){  
        return new MailSender();  
    }  
      
    public Sender produceSms(){  
        return new SmsSender();  
    }  
}

测试类如下：

public class FactoryTest {  
  
    public static void main(String[] args) {  
        SendFactory factory = new SendFactory();  
        Sender sender = factory.produceMail();  
        sender.Send();  
    }  
}

输出：this is mailsender!

03、多个静态方法

将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。

public class SendFactory {  
      
    public static Sender produceMail(){  
        return new MailSender();  
    }  
      
    public static Sender produceSms(){  
        return new SmsSender();  
    }  
}

测试类如下：

public class FactoryTest {  
  
    public static void main(String[] args) {      
        Sender sender = SendFactory.produceMail();  
        sender.Send();  
    }  
}

输出：this is mailsender!

总结：

总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。

1、工厂方法模式（Factory Method）

简单工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到工厂方法模式，创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

请看例子：

public interface Sender {  
    public void Send();  
}

两个实现类：

public class MailSender implements Sender {  
    @Override  
    public void Send() {  
        System.out.println("this is mailsender!");  
    }  
}

public class SmsSender implements Sender {  
    @Override  
    public void Send() {  
        System.out.println("this is sms sender!");  
    }  
}

工厂类

public interface Provider {  
    public Sender produce();  
}

两个工厂类：

public class SendMailFactory implements Provider {  
    @Override  
    public Sender produce(){  
        return new MailSender();  
    }  
}

public class SendSmsFactory implements Provider{  
    @Override  
    public Sender produce() {  
        return new SmsSender();  
    }  
}

测试类：

public class Test {  
  
    public static void main(String[] args) {  
        Provider provider = new SendMailFactory();  
        Sender sender = provider.produce();  
        sender.Send();  
    }  
}

输出:this is mailsender!

总结：

其实这个模式的好处就是，如果你现在想增加一个功能：发及时信息，则只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好！

一个抽象产品类，可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类只能创建一个具体产品类的实例。

2、抽象工厂模式

为了弄清楚上面的结构，我们使用具体的产品和工厂来表示上面的UML类图，能更加清晰的看出模式是如何演变的：

PC类：定义PC产品的接口(AbstractPC)

public interface PC {
    void make();
}

Phone类：定义Phone类产品的接口(AbstractPhone)

public interface Phone {
    void make();
}

MiPC类：定义小米电脑产品(MIPC)

public class MiPC implements PC {
    public MiPC() {
        this.make();
    }
    @Override
    public void make() {
        // TODO Auto-generated method stub
        System.out.println("make xiaomi PC!");
    }
}

MiPhone类：定义小米手机产品(MIPhone)

public class MiPhone implements Phone {
    public MiPhone() {
        this.make();
    }
    @Override
    public void make() {
        // TODO Auto-generated method stub
        System.out.println("make xiaomi Phone!");
    }
}

MAC类：定义苹果电脑产品(MAC)

public class MAC implements PC {
    public MAC() {
        this.make();
    }
    @Override
    public void make() {
        // TODO Auto-generated method stub
        System.out.println("make MAC!");
    }
}

MAC类：定义苹果手机产品(IPhone)

public class IPhone implements Phone {
    public IPhone() {
        this.make();
    }
    @Override
    public void make() {
        // TODO Auto-generated method stub
        System.out.println("make IPhone!");
    }
}

下面需要修改工厂相关的类的定义：

AbstractFactory类：增加PC产品制造接口

public interface AbstractFactory {
    Phone makePhone();
    PC makePC();
}

XiaoMiFactory类：增加小米PC的制造（ConcreteFactory1）

public class XiaoMiFactory implements AbstractFactory{
    @Override
    public Phone makePhone() {
        return new MiPhone();
    }
    @Override
    public PC makePC() {
        return new MiPC();
    }
}

AppleFactory类：增加苹果PC的制造（ConcreteFactory2）

public class AppleFactory implements AbstractFactory {
    @Override
    public Phone makePhone() {
        return new IPhone();
    }
    @Override
    public PC makePC() {
        return new MAC();
    }
}

测试类

public class Demo {
    public static void main(String[] arg) {
        AbstractFactory miFactory = new XiaoMiFactory();
        AbstractFactory appleFactory = new AppleFactory();
        miFactory.makePhone();            // make xiaomi phone!
        miFactory.makePC();                // make xiaomi PC!
        appleFactory.makePhone();        // make iphone!
        appleFactory.makePC();            // make MAC!
    }
}

总结

多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类，可以派生出多个具体工厂类。每个具体工厂类可以创建多个具体产品类的实例，也就是创建的是一个产品线下的多个产品。

区别

工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。工厂方法创建 "一种" 产品，他的着重点在于"怎么创建"，也就是说如果你开发，你的大量代码很可能围绕着这种产品的构造，初始化这些细节上面。也因为如此，类似的产品之间有很多可以复用的特征，所以会和模版方法相随。

抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

对于java来说，你能见到的大部分抽象工厂模式都是这样的： ---它的里面是一堆工厂方法，每个工厂方法返回某种类型的对象。

比如说工厂可以生产鼠标和键盘。那么抽象工厂的实现类（它的某个具体子类）的对象都可以生产鼠标和键盘，但可能工厂A生产的是罗技的键盘和鼠标，工厂B是微软的。

这样A和B就是工厂，对应于抽象工厂；每个工厂生产的鼠标和键盘就是产品，对应于工厂方法；

用了工厂方法模式，你替换生成键盘的工厂方法，就可以把键盘从罗技换到微软。但是用了抽象工厂模式，你只要换家工厂，就可以同时替换鼠标和键盘一套。如果你要的产品有几十个，当然用抽象工厂模式一次替换全部最方便（这个工厂会替你用相应的工厂方法）

所以说抽象工厂就像工厂，而工厂方法则像是工厂的一种产品生产线

3、单例模式（Singleton）

单例对象（Singleton）是一种常用的设计模式。在Java应用中，类私有了构造方法，能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

2、省去了new操作符，降低了系统内存的使用频率，减轻GC压力。

3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

1.饿汉式单例模式：

public class Singleton {  
  
    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  
    private static Singleton instance = new Singleton();  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 静态工程方法，创建实例 */  
    public static Singleton getInstance() {  
        return instance;  
    }  
  
    /* 如果该对象被用于序列化，可以保证对象在序列化前后保持一致 */  
    public Object readResolve() {  
        return instance;  
    }  
}

总结：

类加载时就创建，线程安全。但不用的话也会被创建，耗费内存。

2.懒汉式单例

public class Singleton {  
  
    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  
    private static Singleton instance = null;  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 静态工程方法，创建实例 */  
    public static Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        return instance;  
    }  
  
}

由于线程不安全，修改如下：

public class Singleton {  
  
    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  
    private static Singleton instance = null;  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 静态工程方法，创建实例 */  
    public static synchronized Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        return instance;  
    }  
}

但是，使用synchronized加锁的话，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。修改如下：

public class Singleton {  
  
    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  
    private static Singleton instance = null;  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 静态工程方法，创建实例 */  
    public static Singleton getInstance() {  
        if (instance == null) {  
            synchronized (instance) {  
                if (instance == null) {  
                    instance = new Singleton();  
                }  
            }  
        }  
        return instance;  
    }
}

似乎解决了之前提到的问题，将synchronized关键字加在了内部，也就是说当调用的时候是不需要加锁的，只有在instance为null，并创建对象的时候才需要加锁，性能有一定的提升。但是，这样的情况，还是有可能有问题的，看下面的情况：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例。这样就可能出错了，我们以A、B两个线程为例：

a>A、B线程同时进入了第一个if判断

b>A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton();

c>由于JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块。

d>B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。

e>此时B线程打算使用Singleton实例，却发现它没有被初始化，于是错误发生了。所以程序还是有可能发生错误，其实程序在运行过程是很复杂的，从这点我们就可以看出，尤其是在写多线程环境下的程序更有难度，有挑战性。我们对该程序做进一步优化,改进如下：

public class Singleton {  
  
    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */  
    private volatile static Singleton instance = null;  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 静态工程方法，创建实例 */  
    public static Singleton getInstance() {  
        if (instance == null) {  
            synchronized (instance) {  
                if (instance == null) {  
                    instance = new Singleton();  
                }  
            }  
        }  
        return instance;  
    }
}

总结

volatile修饰的共享变量；

保证可见性，变量都是从主存进行操作；

部分保证顺序性，禁止指令重排序，建立内存屏障

3.静态内部类

public class Singleton {  
  
    /* 私有构造方法，防止被实例化 */  
    private Singleton() {  
    }  
  
    /* 此处使用一个内部类来维护单例 */  
    private static class SingletonFactory {  
        private static Singleton instance = new Singleton();  
    }  
  
    /* 获取实例 */  
    public static Singleton getInstance() {  
        return SingletonFactory.instance;  
    }  
  
}

总结：

实际情况是，单例模式使用内部类来维护单例的实现，JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心上面的问题。同时该方法也只会在第一次调用的时候使用互斥机制，这样就解决了低性能问题。这样我们暂时总结一个完美的单例模式。

其实说它完美，也不一定，如果在构造函数中抛出异常，实例将永远得不到创建，也会出错。所以说，十分完美的东西是没有的，我们只能根据实际情况，选择最适合自己应用场景的实现方法。

4、建造者模式或生成器模式（Builder）

生成器模式是一种创建型设计模式，它把对象的创建步骤抽象成生成器，并且可以通过指导类（director）对所有生成步骤的先后顺序进行控制。客户端使用指导类并传入相应的生成器，通过指导类的接口便可以得到相应的对象。

以我的理解看，生成器模式中的生成器被用来对生成对象的每一个步骤自身进行控制，比如要产生一辆汽车（最终对象），那么玻璃是用普通玻璃还是防弹玻璃（生成最终对象的一个步骤）。而指导类主要用来设置各个步骤之间的次序与取舍，比如先安装门还是先安装玻璃，要不要安装座垫加热。

下面以一辆汽车的生产为例。

首先是汽车类接口：

interface CarPlan {
    void setWheel(String wheel);
    void setFrame(String frame);
    void setEngine(String engine);
    void setWidget(String widget);
}

class Car implements CarPlan {
    private String myWheel;
    private String myFrame;
    private String myEngine;
    private String myWidget;
    void setWheel(String wheel) {
        myWheel = wheel;
    }
    void setFrame(String frame) {
        myFrame = frame;
    }
    void setEngine(String engine) {
        myEngine = engine;
    }
    void setWidget(String widget) {
        myWidget = widgetl
    }
}

然后生成器接口：

interface Builder {
    void buildWheel();
    void buildFrame();
    void buildEngine();
    void buildWidget();
    Car getCar();
}

一个廉价车生成器

class CheapBuilder implements Builder {
    Car cheapCar = new Car();
    Car getCar() {
        return cheapCar;
    }
    void buildWheel() {
        cheapCar.setWheel("cheap wheel");
    }
    void buildFrame() {
        cheapCar.setFrame("cheap frame");
    }
    void buildEngine() {
        cheapCar.setEngine("cheap engine");
    }
    void buildWidget() {
        cheapCar.setWidget("no widget");
    }
}

一个平价车生成器

class EconomicBuilder implements Builder {
    Car economicCar = new Car();
    Car getCar() {
        return economicCar;
    }
    void buildWheel() {
        cheapCar.setWheel("cheap wheel");
    }
    void buildFrame() {
        cheapCar.setFrame("expensive frame");
    }
    void buildEngine() {
        cheapCar.setEngine("cheap engine");
    }
    void buildWidget() {
        cheapCar.setWidget("economic widget");
    }
}

创建指导类：

class Director {
    private Builder builder;
    director(Builder bld) {
        builder = bld;
    }
    void produceCar() {
        //这里对步骤进行控制
        builder.buildFrame();
        builder.buildWidget();
        builder.buildWheel();
        builder.buildEngine();
    }
    Car getCar() {
        builder.getCar();
    }
}

测试类：

public class Test {
    public static void main(String[] args) {
        Builder bld = new EconomicBuilder();
        Director director = new Director(bld);
        director.produceCar();
        Car car = director.getCar();
}

总结

生成器模式与抽象工厂模式看起来很像，其实有很多不同。首先抽象工厂模式更注重于“系列”，即要创建的产品族分为不同的系列，同一系列中的产品是固定的，创建的步骤也是固定的。而生成器模式的重点在于对创建过程中每一个步骤的精细控制以及步骤间次序的控制，这些在抽象工厂模式中是不方便进行控制的（甚至需要修改或创建新的工厂抽象类）。

5、原型模式（Prototype）

从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。原形类如下

public class Prototype implements Cloneable {  
  
    public Object clone() throws CloneNotSupportedException {  
        Prototype proto = (Prototype) super.clone();  
        return proto;  
    }  
}

很简单，一个原型类，只需要实现Cloneable接口，覆写clone方法，此处clone方法可以改成任意的名称，因为Cloneable接口是个空接口，你可以任意定义实现类的方法名，如cloneA或者cloneB，因为此处的重点是super.clone()这句话，super.clone()调用的是Object的clone()方法，而在Object类中，clone()是native的。在这儿，我将结合对象的浅复制和深复制来说一下，首先需要了解对象深、浅复制的概念：

浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。

深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。简单来说，就是深复制进行了完全彻底的复制，而浅复制不彻底。

深浅复制的例子：

public class Prototype implements Cloneable, Serializable {  
  
    private static final long serialVersionUID = 1L;  
    private String string;  
  
    private SerializableObject obj;  
  
    /* 浅复制 */  
    public Object clone() throws CloneNotSupportedException {  
        Prototype proto = (Prototype) super.clone();  
        return proto;  
    }  
  
    /* 深复制 */  
    public Object deepClone() throws IOException, ClassNotFoundException {  
  
        /* 写入当前对象的二进制流 */  
        ByteArrayOutputStream bos = new ByteArrayOutputStream();  
        ObjectOutputStream oos = new ObjectOutputStream(bos);  
        oos.writeObject(this);  
  
        /* 读出二进制流产生的新对象 */  
        ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());  
        ObjectInputStream ois = new ObjectInputStream(bis);  
        return ois.readObject();  
    }  
  
    public String getString() {  
        return string;  
    }  
  
    public void setString(String string) {  
        this.string = string;  
    }  
  
    public SerializableObject getObj() {  
        return obj;  
    }  
  
    public void setObj(SerializableObject obj) {  
        this.obj = obj;  
    }  
  
}  
  
class SerializableObject implements Serializable {  
    private static final long serialVersionUID = 1L;  
}

要实现深复制，需要采用流的形式读入当前对象的二进制输入，再写出二进制数据对应的对象。

四、结构模式（7种）

其中对象的适配器模式是各种模式的起源，我们看下面的图：

6、适配器模式

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

a.类的适配器模式

核心思想就是：有一个Source类，拥有一个方法，待适配，目标接口是Targetable，通过Adapter类，将Source的功能扩展到Targetable里，看代码：

public class Source {

    public void method1() {
        System.out.println("this is original method!");
    }
}
public interface Targetable {

    /* 与原类中的方法相同 */
    public void method1();

    /* 新类的方法 */
    public void method2();
}
public class Adapter extends Source implements Targetable {

    @Override
    public void method2() {
        System.out.println("this is the targetable method!");
    }
}
Adapter类继承Source类，实现Targetable接口，下面是测试类：

public class AdapterTest {

    public static void main(String[] args) {
        Targetable target = new Adapter();
        target.method1();
        target.method2();
    }
}

输出：

this is original method!
this is the targetable method!

这样Targetable接口的实现类就具有了Source类的功能。

b.对象的适配器模式

基本思路和类的适配器模式相同，只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。看图：

只需要修改Adapter类的源码即可：

public class Wrapper implements Targetable {

    private Source source;

    public Wrapper(Source source){
        super();
        this.source = source;
    }
    @Override
    public void method2() {
        System.out.println("this is the targetable method!");
    }

    @Override
    public void method1() {
        source.method1();
    }
}

测试类：

public class AdapterTest {

    public static void main(String[] args) {
        Source source = new Source();
        Targetable target = new Wrapper(source);
        target.method1();
        target.method2();
    }
}
输出与第一种一样，只是适配的方法不同而已。

c.接口的适配器模式

有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有时比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。看一下类图：

这个很好理解，在实际开发中，我们也常会遇到这种接口中定义了太多的方法，以致于有时我们在一些实现类中并不是都需要。看代码：

public interface Sourceable {

    public void method1();
    public void method2();
}

抽象类Wrapper2：

public abstract class Wrapper2 implements Sourceable{

    public void method1(){}
    public void method2(){}
}

public class SourceSub1 extends Wrapper2 {
    public void method1(){
        System.out.println("the sourceable interface's first Sub1!");
    }
}

public class SourceSub2 extends Wrapper2 {
    public void method2(){
        System.out.println("the sourceable interface's second Sub2!");
    }
}

测试类：

public class WrapperTest {

    public static void main(String[] args) {
        Sourceable source1 = new SourceSub1();
        Sourceable source2 = new SourceSub2();

        source1.method1();
        source1.method2();
        source2.method1();
        source2.method2();
    }
}

测试输出：

the sourceable interface's first Sub1!
the sourceable interface's second Sub2!

总结：

讲了这么多，总结一下三种适配器模式的应用场景：

类适配器模式，继承源类，实现目标接口。
对象适配器模式，持有源类的对象，把继承关系改变为组合关系。
接口适配器模式，借助中间抽象类空实现目标接口所有方法，适配器选择性重写。

7、装饰模式（Decorator）

顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例，关系图如下：

Source类是被装饰类，Decorator类是一个装饰类，可以为Source类动态的添加一些功能，代码如下：

被装饰类和装饰类共同实现的接口

public interface Sourceable {  
    public void method();  
}

被装饰类

public class Source implements Sourceable {  
  
    @Override  
    public void method() {  
        System.out.println("the original method!");  
    }  
}

装饰类（引用了对象适配器）

public class Decorator implements Sourceable {  
  
    private Sourceable source;  
      
    public Decorator(Sourceable source){  
        super();  
        this.source = source;  
    }  
    @Override  
    public void method() {  
        System.out.println("before decorator!");  
        source.method();  
        System.out.println("after decorator!");  
    }  
}

测试类：

public class DecoratorTest {  
  
    public static void main(String[] args) {  
        Sourceable source = new Source();  
        Sourceable obj = new Decorator(source);  
        obj.method();  
    }  
}

输出：

before decorator!
the original method!
after decorator!

总结：

装饰器模式的应用场景：

1、需要扩展一个类的功能。

2、动态的为一个对象增加功能，而且还能动态撤销。（继承不能做到这一点，继承的功能是静态的，不能动态增删。）

缺点：产生过多相似的对象，不易排错！

8、代理模式（Proxy）

代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。再如我们有的时候打官司，我们需要请律师，因为律师在法律方面有专长，可以替我们进行操作，表达我们的想法。先来看看关系图：

01.静态代理：

根据上文的阐述，代理模式就比较容易的理解了，我们看下代码：

public interface Sourceable {  
    public void method();  
}

public class Source implements Sourceable {  
  
    @Override  
    public void method() {  
        System.out.println("the original method!");  
    }  
}

public class Proxy implements Sourceable {  
  
    private Source source;  
    public Proxy(){  
        super();  
        this.source = new Source();  
    }  
    @Override  
    public void method() {  
        before();  
        source.method();  
        atfer();  
    }  
    private void atfer() {  
        System.out.println("after proxy!");  
    }  
    private void before() {  
        System.out.println("before proxy!");  
    }  
}

测试类：

public class ProxyTest {  
  
    public static void main(String[] args) {  
        Sourceable source = new Proxy();  
        source.method();  
    }  
  
}

输出：

before proxy!
the original method!
after proxy!

代理模式的应用场景：

如果已有的方法在使用的时候需要对原有的方法进行改进，此时有两种办法：

1、修改原有的方法来适应。这样违反了“对扩展开放，对修改关闭”的原则。

2、就是采用一个代理类调用原有的方法，且对产生的结果进行控制。这种方法就是代理模式。

优点：使用代理模式，可以将功能划分的更加清晰，有助于后期维护！

缺点：是一旦接口中增加方法，实现这个接口的房东和中介都要做出修改。

02.动态代理

要解决静态代理的问题，可使用动态代理的方式

动态代理有两类，一是基于接口的JDK动态代理，另外一种是基于类的CGLib代理

idk代理类

写法1

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * jdk动态代理，不需要实现接口，需要指定接口类型
 * 写法一，好理解，以租房为例的话，targetObject就是Rent接口
 */
public class JDKProxy implements InvocationHandler {

    //需要代理的目标对象。
    //targetObject就是咱们的Rent接口
    public Object targetObject;
    //代理对象目标
    public void setTargetObject(Object targetObject) {
        this.targetObject = targetObject;
    }

    //生成得到代理类
    public Object getTargetObject(){
        /**
         * 返回代理对象
         * 参数一：指定当前目标对象使用的类加载器。
         * 参数二：目标对象实现的接口的类型。
         * 参数三：事件处理器。这里写的this是代表下边重写的invoke方法
         */
        return Proxy.newProxyInstance(
                targetObject.getClass().getClassLoader(),
                targetObject.getClass().getInterfaces(),
                this);
    }

    /**
     * 实现InvocationHandler接口，就要重写invoke方法。
     * proxy，调用该方法的代理实例
     * method，要执行的目标对象的方法(利用反射的原理)
     * args，执行某方法需要的参数。
     */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

        seeHouse();//看房
        //动态代理的本质，就是使用反射机制实现
        Object result = method.invoke(targetObject,args);
        hetong();//签合同
        fare();//收费
        return result;
    }

    public void seeHouse(){
        System.out.println("中介带你看房子");
    }
    public void hetong(){
        System.out.println("签订租赁合同");
    }
    public void fare(){
        System.out.println("收中介费");
    }
}

测试类：

public class client2 {
    public static void main(String[] args) {
        //真实角色
        Source source= new Source();

        //代理角色,现在没有
        JDKProxy jdkProxy = new JDKProxy();

        //通过调用程序处理角色来处理我们要用调用的接口对象
        jdkProxy.setTargetObject(source);//把要代理的对象传过去

        Sourceable proxy = (Sourceable) jdkProxy.getTargetObject();
        proxy.method();
    }
}

写法2

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * 创建动态代理对象
 * 动态代理不需要实现接口,但是需要指定接口类型
 */
public class ProxyFactory {

    //目标对象
    private Object target;
    public ProxyFactory(Object target) {
        this.target = target;
    }

    //给目标对象生成代理对象
    public Object getProxyInstance() {
        return Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                target.getClass().getInterfaces(),
                new InvocationHandler() {
                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        seeHouse();
                        //执行目标对象方法
                        Object returnValue = method.invoke(target, args);
                        hetong();
                        fare();
                        return returnValue;
                    }
                }
        );
    }
    
    public void seeHouse(){
        System.out.println("中介带你看房子");
    }
    public void hetong(){
        System.out.println("签订租赁合同");
    }
    public void fare(){
        System.out.println("收中介费");
    }
}

测试类：

public class client3 {
    public static void main(String[] args) {
        //目标对象
        Source source= new Source();

        //给目标对象创建代理对象
        Sourceable proxy = (Sourceable) new ProxyFactory(source).getProxyInstance();

        //执行方法
        proxy.method();
    }
}

总结：

代理对象不用实现接口，但目标对象（房东host）一定要实现接口（Rent），否则不能使用JDK动态代理。

03.CGLib代理

需要导入CGLib的jar文件，但spring的核心已包括了CGLib的功能，可以直接导入spring的核心包。

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>5.2.9.RELEASE</version>
</dependency>

（1）CGLib代理工厂类

import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;

import java.lang.reflect.Method;

/**
 * CGLib子类代理工厂:内存中动态构建一个子类对象
 */
public class CGLibProxyFactory implements MethodInterceptor {
    //目标对象
    private Object target;
    public CGLibProxyFactory(Object target) {
        this.target = target;
    }

    //给目标对象创建一个代理对象
    public Object getProxyInstance(){
        //1、工具类
        Enhancer en = new Enhancer();
        //2、设置父类
        en.setSuperclass(target.getClass());
        //3、设置回调函数
        en.setCallback(this);
        //4、创建子类(代理对象)
        return en.create();
    }

    @Override
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
        seeHouse();//看房

        //执行目标对象的方法
        Object returnValue = method.invoke(target, args);

        hetong();//签合同
        fare();//收费
        return returnValue;
    }

    public void seeHouse(){
        System.out.println("中介带你看房子");
    }
    public void hetong(){
        System.out.println("签订租赁合同");
    }
    public void fare(){
        System.out.println("收中介费");
    }
}

Enhancer是cglib中使用频率很高的一个类，它是一个字节码增强器，可以用来为无接口的类创建代理。

测试类：

public class client4 {
    public static void main(String[] args) {
        //目标对象
        Source source= new Source();
        //生成代理对象
        Source proxy = (Source) new CGLibProxyFactory(source).getProxyInstance();
        //执行代理对象的方法
        proxy.method();
    }
}

总结：

Spring在选择用JDK还是CGLiB的依据：

(1)当Bean实现接口时，Spring就会用JDK的动态代理

(2)当Bean没有实现接口时，Spring使用CGlib是实现

(3)可以强制使用CGlib，只需要在spring配置中加入

<aop:aspectj-autoproxy proxy-target-class="true"/>

CGLib和JDK动态代理的区别

（1）JDK动态代理是实现了被代理对象的接口，CGLib是继承了被代理对象。

（2）JDK和CGLib都是在运行期生成字节码，JDK是直接写Class字节码，CGLib使用ASM框架写Class字节码，CGLib代理实现更复杂，生成代理类比JDK效率低。

（3）JDK调用代理方法，是通过反射机制调用，CGLib是通过FastClass机制直接调用方法，CGLib执行效率更高。

9、外观模式（Facade）

外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口，看下类图：（我们以一个计算机的启动过程为例）

我们先看下实现类：

JAVA设计模式总结

一、设计模式的分类

二、设计模式的六大原则

三、创建型模式

0、简单工厂模式

01、普通

02、多个方法

03、多个静态方法

1、工厂方法模式（Factory Method）

2、抽象工厂模式

3、单例模式（Singleton）

4、建造者模式或生成器模式（Builder）

5、原型模式（Prototype）

四、结构模式（7种）

6、适配器模式

7、装饰模式（Decorator）

8、代理模式（Proxy）

9、外观模式（Facade）

10、桥接模式（Bridge）

11、组合模式（Composite）

12、享元模式（Flyweight）

五、关系模式（11种）

父类与子类关系

13、策略模式（strategy）

14、模板方法模式（Template Method）

类之间的关系

15、观察者模式（Observer）

16、迭代子模式（Iterator）

17、责任链模式（Chain of Responsibility）

18、命令模式（Command）

类的状态

19、备忘录模式（Memento）

20、状态模式（State）

通过中间类

21、访问者模式（Visitor）

22、中介者模式（Mediator）

23、解释器模式（Interpreter）