简述面向对象设计原则以及常用设计模式

类之间的关系

在软件系统中，类不是孤立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

依赖关系

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关系。在代码中，某个类的方法通过局部变量、方法参数或者对静态方法的调用来访问另一个类(被依赖的类)中的某些方法来实现一些功能。

关联关系

关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类之间最常用的一种关系。分为一般关联关系、聚合关系和组合关系。

• 一般关联：关联可以是单向的也可以是双向的，在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系。

  

• 聚合关联：聚合关联是关联关系的一种，是强关联关系，使整体和部分之间的关系。聚合关联也是通过成员对象的方式实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如学校与老师的关系，学校包含老师，但是如果学校停办了，老师依然存在。

  

• 组合关系：组合关系也是关联关系的一种，也表示类之间的整体与部分的关系，但它是更为强烈的聚合关系。在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在了，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如头和嘴的关系，没有了头，嘴也就不存在了。

  

泛化关系

泛化关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类和子类之间的关系，是一种继承关系。在代码实现中，使用面向对象的继承来实现泛化关系。例如Student和Teacher都是Person的子类。

实现关系

实现关系是接口与实现类之间的关系，在这种关系中，类实现了接口，类中的操作实现了接口所声明的所有抽象操作。例如汽车和船实现了交通工具。

面向对象设计原则

开闭原则(对扩展开放，对修改关闭)

当应用的需求需要改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

开闭原则的作用

• 开闭原则是面对对象程序设计的终极目标，它使得实体拥有一定的适应性和灵活性的同时具有稳定性和延续性。
• 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然可以正常运行。
• 粒度越小，被复用的可能性就越大，在面对象的程序设计中，根据原子和抽象变成可以提高代码的可服用性。
• 遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

开闭原则的实现方式

• 可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
• 因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

里氏替换原则(继承必须确保超类所拥有的性质在子类中仍然成立)

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

里氏替换的作用

• 里氏替换原则是实现开闭原则的重要方式之一
• 它客服了继承中重写父类造成的可复用性变差的缺点
• 它是动作正确性的保证，即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

里氏替换的实现方式

• 里氏替换原则通俗来说讲就是：子类可以扩展父类的功能，但是不能改变父类原有的功能。也就是说，子类继承父类时，除了添加新的方法完成新增功能外，尽量不要重写父类的方法。
• 如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
• 如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

依赖倒置(面向接口编程，不要面向实现编程)

高层次模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖于细节，细节应该依赖于抽象。依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。

依赖、倒置原则的作用

• 依赖倒置原则可以降低类间的耦合性。
• 依赖倒置原则可以提高系统的稳定性。
• 依赖倒置原则可以减少并行开发引起的风险。
• 依赖倒置原则可以提高代码的可读性和可维护性。

依赖、倒置的实现方式

• 依赖倒置原则的目的是通过面向接口的编程方式来降低类之间的耦合
• 每个类尽量提供接口或者抽象类，或者两者都具备
• 变量的声明类型尽量是接口或者抽象类
• 任何类都不应该从具体类派生
• 使用继承时尽量遵循里氏替换原则

单一职责原则的定义(单一功能原则)

单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。 对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

• 1.一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
• 2.当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的优点

• 单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。
• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
• 提高类的可读性。复杂性降低，自然其可读性会提高。
• 提高系统的可维护性。可读性提高，那自然更容易维护了。
• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则的实现方法 单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。下面以大学学生工作管理程序为例介绍单一职责原则的应用。

接口隔离原则

接口隔离原则的定义

• 接口隔离原则要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
• 客户端不应该被迫依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上。
• 要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

• 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

接口隔离原则的优点

• 接口隔离原则是为了约束接口、降低类对接口的依赖性。
• 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
• 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
• 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
• 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
• 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

接口隔离原则的实现方法

• 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则(最少知识原则)

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话。 含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则的优点

• 迪米特法则要求限制软件实体之间通信的宽度和深度
• 降低了类之间的耦合度，提高了模块的相对独立性。
• 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

迪米特法则的实现方法

• 从依赖者的角度来说，只依赖应该依赖的对象。
• 从被依赖者的角度说，只暴露应该暴露的方法。

使用迪米特法则时的注意点

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
• 在类的结构设计上，尽量降低类成员的访问权限。
• 在类的设计上，优先考虑将一个类设置成不变类。
• 在对其他类的引用上，将引用其他对象的次数降到最低。
• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
• 谨慎使用序列化（Serializable）功能。

合成复用原则(组合/聚合复用原则)

要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。 如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

合成复用原则的重要性

• 通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
• 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
• 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
• 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
• 采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
• 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
• 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
• 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

合成复用原则的实现方法 合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

创建型模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。

创建型模式分为以下几种

• 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
• 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
• 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
• 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
• 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

单例模式

单例模式的结构和实现

• 构造起私有化
• 向外部提供一个静态的共有函数用于创建或者获取该类的私有实例

单例模式特点

• 单例对象只有一个实例对象
• 该单例对象必须由单例类自行创建
• 单例类对外提供一个访问该单例的全局访问点

应用场景

• 某类只要求生成一个对象
• 如Web中的配置对象、数据库连接池、多线程的线程池、网络连接池

/**
 * 单例模式 懒汉式 双重锁机制，线程安全
 */
public class Singleton_1 {
    private static volatile Singleton_1 s;
    private Singleton_1() {
    }
    public static Singleton_1 getInstance() {
        if (s == null) {
            synchronized (Singleton_1.class) {
                if (s == null) {
                    s = new Singleton_1();
                }
            }
        }
        return s;
    }
}

/**
 * 懒汉式单例模式 线程安全，使用静态内部类
 */
public class Singleton_2 {
    private Singleton_2() {
    }
    private static class SingletonHandler {
        private static final Singleton_2 singleton = new Singleton_2();
    }
    public static Singleton_2 getInstance() {
        return SingletonHandler.singleton;
    }
}

/**
 * 懒汉式 线程不安全
 */
public class Singleton_3 {
    private static Singleton_3 singleton;
    private Singleton_3() {
    }
    public static Singleton_3 getSingleton() {
        if (singleton != null) {
        } else {
            singleton = new Singleton_3();
        }
        return singleton;
    }
}

/**
 * 单例模式 饿汉式
 */
public class Singleton_2 {
    public static final Singleton_2 s = new Singleton_2();
    private Singleton_2() {
    }
    public static Singleton_2 getInstance() {
        return s;
    }
}

原型模式

原型模式定义

用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型对象相同或者相似的新对象。

原型模式的结构与实现

由于Java的Object类提供了clone方法，所以用Java实现原型模式很简单

原型模式的克隆分为浅克隆和深克隆，Java中的Object类提供了浅克隆的clone方法，具体原型类只要实现Cloneable接口就可以实现对象的浅克隆，Cloneable就是抽象类原型

原型模式的特点

• 原型模式主要包含以下特点：
• 抽象原型类：规定了具体原型对象必须实现的接口
• 具体原型类：实现抽象原型类的clone方法，它时可被复制的对象
• 访问类：使用具体原型类中的clone方法来复制新的对象

/**
 * 原型模式
 */
public class RealizeTpye implements Cloneable {
    public RealizeTpye() {
        System.out.println("具体原型创建成功！");
    }
    public Object clone() throws CloneNotSupportedException {
        System.out.println("具体原型类复制成功！");
        return (RealizeTpye) super.clone();
    }
}

原型模式饿应用场景

• 对象之间相同或相似，即知识个别的几个属性不同的时候
• 对象的创建过程比较麻烦，但是复制比较简单

工厂模式

工厂模式的定义

定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。满足了"创建与使用分离"的特点。 我们把创建的对象成为"产品"，吧创建产品的对象称为工厂。如果需要创建的产品不多，只要有一个工厂类就可以完成，这种模式称为"简单工厂模式"，它的缺点就是增加新的产品时会违反"开闭原则"。

工厂模式的优点

• 用户只需要知道具体工厂的名称就可以得到所要的产品，无需知道产品的具体创建过程。 -在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类即可，无需对原工厂进行修改，满足开闭原则。

工厂模式缺点

每增加一个产品就要增加一个具体产品类和一个对应的工厂类，增加了系统的复杂度。

工厂模式的结构与实现

• 工厂模式由抽象工厂、具体工厂、抽象产品、具体产品等4个要素构成。
• 抽象工厂：提供了创建产品的接口，调用者通过它访问具体工厂的工厂放大newProduct来创建产品。
• 具体工厂：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
• 抽象产品：定义了产品的规格，描述了产品的主要特征和功能。
• 具体产品：实现了抽象产品的角色所定义的接口，由具体的工厂来创建。

//抽象产品：提供了产品的接口
public interface Product {
    public void show();
}

//具体产品1：实现抽象产品中的抽象方法
public class ConcreteProduct1 implements Product {
    public void show() {
        System.out.println("具体产品1显示...");
    }
}

//具体产品2：实现抽象产品中的抽象方法
public class ConcreteProduct2 implements Product {
    public void show() {
        System.out.println("具体产品2显示...");
    }
}

// 抽象工厂
public interface AbstractFactory {
    public Product newProduct();
}

//具体工厂1：实现了厂品的生成方法
public class ConcreteFactory1 implements AbstractFactory {
    @Override
    public Product newProduct() {
        System.out.println("具体工厂1生成-->具体产品1...");
        return new ConcreteProduct1();
    }
}

//具体工厂2：实现了厂品的生成方法
public class ConcreteFactory2 implements AbstractFactory {
    public Product newProduct() {
        System.out.println("具体工厂2生成-->具体产品2...");
        return new ConcreteProduct2();
    }
}

//在根目录创建xml配置文件
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <className>ConcreteFactory1</className>
</config>

import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import java.io.File;
public class ReadXML1 {
    //该方法用于从XML配置文件中提取具体类类名，并返回一个实例对象
    public static Object getObject() {
        try {
            //创建文档对象
            DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
            DocumentBuilder builder = dFactory.newDocumentBuilder();
            Document doc;
            doc = builder.parse(new File("/Users/yanghao/Documents/idea_workspace/algorithmAndDatasSructure/datastructure/resource/config1.xml"));
            //获取包含类名的文本节点
            NodeList nl = doc.getElementsByTagName("className");
            Node classNode = nl.item(0).getFirstChild();
            String cName = "com.designMode.factoryMode." + classNode.getNodeValue();
            //通过类名生成实例对象并将结果返回
            Class<?> c = Class.forName(cName);
            Object obj = c.newInstance();
            return obj;
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
}

//测试类
public class AbstractFactoryTest {
    public static void main(String[] args) {
        Product a;
        AbstractFactory af;
        af = (AbstractFactory) ReadXML1.getObject();
        a = af.newProduct();
        a.show();
    }
}

工厂模式的应用场景

• 客户只知道创建产品的工厂名，而不知道具体的产品
• 创建对象的任务由多个子工厂的某一个完成，而抽象工厂只提供创建产品的接口
• 客户不关心创建产品的细节，只关心产品的生产

建造者模式

建造者模式定义

将一个复杂对象的构造与它的表示分离，使同样的构造可以创建不同的表示。是将一个复杂的对象分解为多个简单的对象，一步一步的构建。

建造者模式优点

• 各个具体的建造者相互独立，有利于系统的扩展
• 客户端不必知道产品内部组成的细节，便于控制细节风险

建造者模式缺点

• 产品的组成必须相同，限制了使用范围
• 如果产品的内部变化复杂，则需要很多建造者

建造者模式的结构与实现

• 建造者(Builder)模式由产品、抽象建造者、具体建造者、指挥者四部分组成。
• 产品角色：包含了多个组成部件的复杂对象，由具体建造者来创建各个组件。
• 抽象建造者：是一个包含创建产品各个子部件的抽象方法的抽象类，通常还包含一个返回复杂产品的方法。
• 具体建造者：继承了抽象建造者，完成复杂产品的各个部件的具体创建方法。
• 指挥者：调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。

public class Product {
    private String partA;
    private String partB;
    private String partC;

    public void setPartA(String partA) {
        this.partA = partA;
    }
    public void setPartB(String partB) {
        this.partB = partB;
    }
    public void setPartC(String partC) {
        this.partC = partC;
    }
    @Override
    public String toString() {
        return "Product{" +
                "partA='" + partA + '\'' +
                ", partB='" + partB + '\'' +
                ", partC='" + partC + '\'' +
                '}';
    }
    public String show() {
        return toString();
    }
}

abstract class Builder {
    protected Product product = new Product();
    public abstract void buildPartA();
    public abstract void buildPartB();
    public abstract void buildPartC();
    public Product getResult() {
        return product;
    }
}

public class ConcreteBuilder extends Builder {
    @Override
    public void buildPartA() {
        super.product.setPartA("建造partA");
    }
    @Override
    public void buildPartB() {
        super.product.setPartB("建造partB");
    }
    @Override
    public void buildPartC() {
        super.product.setPartC("建造partC");
    }
}

public class Director {
    private Builder builder;
    public Director(Builder builder) {
        this.builder = builder;
    }
    public Product construct() {
        builder.buildPartA();
        builder.buildPartB();
        builder.buildPartC();
        return builder.getResult();
    }
}

public class Client {
    public static void main(String[] args) {
        Builder builder = new ConcreteBuilder();
        Director director = new Director(builder);
        Product product = director.construct();
        System.out.println(product.show());
    }
}

建造者模式的使用场景

建造者模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但是他们组合在一起的算法却相对稳定。

• 创建的对象较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。
• 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表示是独立的。

结构型模式

结构型模式的定义

结构性模式描述如何将类或者对象按照某种布局组成更大的结构。分为类结构型模式和对象接口型模式，前者采用继承机制来组织接口和类，后者采用组成或聚合来组合对象。

结构型模式分类

• 代理(Proxy)模式：为对象提供一种代理以控制对该对象的访问。即客户端通过代理间接的访问该对象，从而限制、增强或者修改该对象的一些特征。
• 适配器模式：将一个类的接口转换为客户端希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• 桥接模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
• 装饰者模式：动态地给对象增加一些职责，即增加其额外的功能。
• 外观模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
• 享元模式：运用共享技术来有效地支持大量细粒度对象的复用。
• 组合模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

代理模式

代理模式的定义

由于某些原因需要给某对象提供一个代理以控制该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象的中介。

代理模式优点

• 代理模式在客户端与目标之间起到一个中介作用和保护目标对象的作用
• 代理对象可以扩展目标对象的功能
• 代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度

代理模式缺点

• 在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢
• 增加了系统复杂性

代理模式的结构与实现

代理模式比较简单，主要是通过定义一个继承抽象类主题的代理来包含真实主题，从而实现对真实主题的访问

• 代理模式的角色：抽象主题类、真实主题类、代理类
• 抽象主题类：通过接口或抽象类声明声明真实主题和代理对象实现的业务方法
• 真实主题类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象。
• 代理(Proxy)类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，它可以访问、控制或扩展真实主题的功能。

代理模式的应用场景

• 远程代理：这种方式通常是为了隐藏目标对象存在于不同地址空间的事实，方便客户端访问。例如，用户申请某些网盘空间时，会在用户的文件系统中建立一个虚拟的硬盘，用户访问虚拟硬盘时实际访问的是网盘空间。
• 虚拟代理：这种方式通常用于要创建的目标对象开销很大时。例如，下载一幅很大的图像需要很长时间，因某种计算比较复杂而短时间无法完成，这时可以先用小比例的虚拟代理替换真实的对象，消除用户对服务器慢的感觉。
• 安全代理：这种方式通常用于控制不同种类客户对真实对象的访问权限。
• 智能指引：主要用于调用目标对象时，代理附加一些额外的处理功能。例如，增加计算真实对象的引用次数的功能，这样当该对象没有被引用时，就可以自动释放它。
• 延迟加载：指为了提高系统的性能，延迟对目标的加载。例如，Hibernate中就存在属性的延迟加载和关联表的延时加载。

适配器模式（Adapter模式）

适配器模式的定义

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

适配器模式的优点

• 客户端通过适配器可以透明地调用目标接口。
• 复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。
• 将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。

模式的结构与实现

类适配器模式可采用多重继承方式实现，如C++可定义一个适配器类来同时继承当前系统的业务接口和现有组件库中已经存在的组件接口；Java不支持多继承，但可以定义一个适配器类来实现当前系统的业务接口，同时又继承现有组件库中已经存在的组件。

适配器模式（Adapter）包含以下主要角色。

• 目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
• 适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
• 适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。

public interface Target {
    public void request();
}

public class Adaptee {
    public void specificRequest() {
        System.out.println("适配者中的业务代码被调用！");
    }
}

//类适配器模式
public class ClassAdapter extends Adaptee implements Target {
    @Override
    public void request() {
        specificRequest();
    }
}

public class ClassAdapterTest {
    public static void main(String[] args) {
        System.out.println("类适配器模式测试：");
        Target target = new ClassAdapter();
        target.request();
    }
}

//对象适配器模式
   class ObjectAdapter implements Target {
    private Adaptee adaptee;
    public ObjectAdapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }
    public void request() {
        adaptee.specificRequest();
    }
}


public class ObjectAdapterTest {
    public static void main(String[] args) {
        System.out.println("对象适配器模式测试：");
        Adaptee adaptee = new Adaptee();
        Target target = new ObjectAdapter(adaptee);
        target.request();
    }
}

适配器模式的应用场景

• 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
• 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。

桥接模式

桥接模式的定义

将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

桥接模式的优点

• 由于抽象与实现分离，所以扩展能力强
• 其实现细节对客户透明

桥接模式的缺点

• 由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度。

桥接模式的结构和实现

• 抽象化角色：定义一个抽象类，并包含一个对实现化对象的引用
• 扩展抽象化角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
• 实现化角色：定义实现化角色的接口，供扩展抽象化角色调用。
• 具体实现化角色：给出实现化角色接口的具体实现。

装饰者模式

装饰者模式定义

指在不改变对象结构的情况下，动态的给该对象添加一些功能的模式。

装饰者模式的优点

• 采用装饰者模式扩展对象的功能比采用继承更加灵活
• 可以设计出多个不同的具体装饰者，创造出不同行为的组合

装饰者模式的缺点

• 装饰者模式增加了许多子类，如果过度使用会使得程序变得很复杂。

装饰模式的结构与实现

• 抽象构建角色：定义一个抽象接口以规范准备接收附加责任的对象
• 具体构件角色：实现抽象构件，通过装饰角色为其添加一些职责。
• 抽象装饰角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
• 具体装饰角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

观察者模式

观察者模式定义

指多个对象之间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得得到通知并自动更新，这种模式又称为发布-订阅模式。

观察者模式的优点

• 降低了目标与观察者之间的耦合关系，两者之间都是抽象耦合关系
• 目标与观察者之间建立了一套触发机制

观察者模式的缺点

• 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
• 当观察者对象很多时，通知的发布会花费很多的时间，影响程序的效率

观察者模式的结构和实现

//抽象目标
abstract class Subject
{
    protected List<Observer> observers=new ArrayList<Observer>();   
    //增加观察者方法
    public void add(Observer observer)
    {
        observers.add(observer);
    }    
    //删除观察者方法
    public void remove(Observer observer)
    {
        observers.remove(observer);
    }   
    public abstract void notifyObserver(); //通知观察者方法
}

//具体目标
class ConcreteSubject extends Subject
{
    public void notifyObserver()
    {
        System.out.println("具体目标发生改变...");
        System.out.println("--------------");       
       
        for(Object obs:observers)
        {
            ((Observer)obs).response();
        }
       
    }          
}

//抽象观察者
interface Observer
{
    void response(); //反应
}

//具体观察者1
class ConcreteObserver1 implements Observer
{
    public void response()
    {
        System.out.println("具体观察者1作出反应！");
    }
}

//具体观察者1
class ConcreteObserver2 implements Observer
{
    public void response()
    {
        System.out.println("具体观察者2作出反应！");
    }
}

public class ObserverPattern
{
    public static void main(String[] args)
    {
        Subject subject=new ConcreteSubject();
        Observer obs1=new ConcreteObserver1();
        Observer obs2=new ConcreteObserver2();
        subject.add(obs1);
        subject.add(obs2);
        subject.notifyObserver();
    }
}