Factory模式

• 1）定义创建对象的接口，封装了对象的创建；
• 2）使得具体化类的工作延迟到了子类中。
• 角色
  • 抽象产品（Product）：是简单工厂创建的所有对象的父类，负责描述所有实例共有的公共接口。
  • 具体产品（ConcreteProduct）：是简单工厂模式的创建目标。

AbstactFactory模式

• 定义：是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。
• 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法 newProduct()，可以创建多个不同等级的产品。
• 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。

• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间是多对一的关系。

  
  

Singleton模式（单例）

• 定义：指一个类只有一个实例，且该类能自行创建这个实例的一种模式
• 角色
  • 单例类：包含一个实例且能自行创建这个实例的类。

  • 访问类：使用单例的类。

    
    

Builder模式（建造者模式）

• 指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示。
• 它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。
• 它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的。
• 高配中配和低配，想选哪配就哪配
• 开放个性配置步骤
• 角色
  • 产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
  • 抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法 getResult()。
  • 具体建造者(Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。

  • 指挥者（Director）：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。

    
    

Prototype模式

• 比如定义一个接口，一个类去实现相应的接口，然后在合适的地方
  调用
• 拔一根猴毛，吹出千万个
• 高效创建对象

桥接（Bridge）模式

• 桥接（Bridge）模式的定义：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

• 桥接（Bridge）模式的优点是：

  • 抽象与实现分离，扩展能力强
  • 符合开闭原则
  • 符合合成复用原则
  • 其实现细节对客户透明

• 可以将抽象化部分与实现化部分分开，取消二者的继承关系，改用组合关系。

• 桥接（Bridge）模式包含以下主要角色。

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

  • 具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。

    
    

class Color {
public:
    virtual string getColor();
};

class Bag {
public:
    Color *color = nullptr;
    
    virtual void setColor(Color *color) {
        this->color = color;
    }
    
    virtual string getName() {
        return "bag";
    }
    
    virtual ~Bag() {
        delete color;
        color = nullptr;
    }
};

class Yellow: public Color {
    
    string getColor() override {
        return  "Yelloow";
    }
};

class Red: public Color {
    
    string getColor() override {
        return  "Red";
    }
};

class HandBag: public Bag {
    string getName() override {
        return "HandBag";
    }
};

class Wallet: public Bag {
    string getName() override {
        return "Wallet";
    }
};


class BagManage {
    void test() {
        Wallet().setColor(new Red());
        HandBag().setColor(new Yellow());
    }
};

代理模式 (Proxy)

• 定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问
• 没有资源没时间，得找别人来帮忙
• 相当于间接访问，不直接访问, 其目的是为了保护一些资源，比如访问一些大文件服务时，连接的过程是保密的，不想直接暴露出来，这样的话，就可以单独使用一个代理类来封装这些业务，然后只暴露一些必要接口
• 优点
  • 在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；
  • 可以扩展目标对象的功能；
  • 能将客户端与目标对象分离，在一定程度上降低了系统的耦合度，增加了程序的可扩展性
• 缺点
  • 会造成系统设计中类的数量增加
  • 在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢；

  • 增加了系统的复杂度；

    
    

// 抽象主题
class Subject {
public:
    virtual void request() = 0;
};

// 真实主题
class RealSubject: public Subject {
public:
    void request() override {
        printf("--RealSubject - request --");
    }
};

// 代理类：不直接使用RealObject访问，而是通过Proxy类间接访问
class Proxy: public Subject {
    RealSubject * m_subject = nullptr;
public:
    void request() override {
        m_subject->request();
    }
};

class Proxyytest {
    void test() {
        // 不直接使用RealObject调用request，而是通过Proxy类间接访问
        Proxy *proxy = new Proxy();
        proxy->request();
    }
};

适配器模式 (Adapter)

• 定义：将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类能在一起工作
• 种类
  • 对象结构型：适配器引用适配者
  • 类结构型：适配器继承是适配者
• 角色
  • 目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
  • 适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
  • 适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者

class Motor {
public:
    virtual void drive() = 0;
};

class ElectricMotor {
public:
    void electricDrive() {
        
    }
};

class OpticalMotor {
public:
    void opticalDrive() {
        
    }
};

class ElecticAdapter: public Motor {
private:
    ElectricMotor *motor = nullptr;
public:
    void drive() override {
        motor->electricDrive();
    }
};


class OpticalAdapter: public Motor {
private:
    OpticalMotor *motor = nullptr;
public:
    void drive() override {
        motor->opticalDrive();
    }
};

class AdapterTest {
public:
    void test() {
        Motor *motor = new OpticalAdapter();
        motor->drive();
    }
};

装饰器模式 (Decorator)

• 定义：在不改变现有对象的结构情况下，动态地该对象增加一些职责

• 说白了，就是在调用了父类的方法之后或者之前，再调用了本类的其他方法

• 角色

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

class Component {
public:
    virtual void operation() = 0;
};

class ConcreteComponent: public Component {
    void operation() override {
        
    }
};

class Decorator: public Component {
public:
    Component *component = nullptr;
    
    void operation() override {
        component->operation();
    }
};

class ConcreteDecorator: public Decorator {
private:
    void addedFunction() {
        
    }
public:
    void operation() override {
        Decorator::operation();
        // 做一些额外的操作
        addedFunction();
    }
    
};

享元模式 (Flyweight)

• 定义: 运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率
• 相当于一个缓存机制，先从factory里面取对象，如果对象的key存在，则直接返回该该对象，不存在在创建，然后放入缓存中
• 角色
  • 抽象享元角色（Flyweight）：是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。
  • 具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。
  • 非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。
  • 享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。
  • 优点: 相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。
  • 缺点: 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。读取享元模式的外部状态会使得运行时间稍微变长。

// 非享元角色
class UnsharedConcreteFlywieght {
    
};

// 抽象享元角色
class Flyweight {
    
public:
    virtual void operation(UnsharedConcreteFlywieght state);
};

// 具体享元角色
class ConcreteFlyweight: public Flyweight {
    
public:
    ConcreteFlyweight(std::string key) {
        
    }
    
    void operation(UnsharedConcreteFlywieght state) override {
        
    }
};

// 享元工厂角色
class FlyweightFactory {
private:
    std::map<std::string, Flyweight*> maps;
    
public:
    Flyweight* getFlyweight(std::string key) {
        Flyweight* flyweight = maps.at(key);
        if (flyweight == nullptr) {
            flyweight = new ConcreteFlyweight(key);
            maps[key] = flyweight;
        } else {
            
        }
        return flyweight;
    }
};

class FlyweightTest {
    void test() {
        FlyweightFactory *facotry = new FlyweightFactory();
        facotry->getFlyweight("a");
        facotry->getFlyweight("a");
        facotry->getFlyweight("b");
        facotry->getFlyweight("b");
    }
};

外观模式（Facade）

• 定义: 又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，

• 对外提供一个统一的接口用来访问子系统

  
  

// 子系统
struct SubSystem01 {
  
    void method1() {
        
    }
};

// 子系统
struct SubSystem02 {
  
    void method2() {
        
    }
};
// 子系统
struct SubSystem03 {
  
    void method2() {
        
    }
};


// 外观角色
class Facade {
    
public:
    void method() {
        SubSystem01 sub01;
        SubSystem02 sub02;
        SubSystem03 sub03;
        sub01.method1();
        sub02.method2();
        sub03.method3();
    }
};

模板方法模式

• 定义：定一个操作中的算法模式，而将算法的一些步骤延迟到子类中，使得子类不改变该算法结构的情况下重定义该算法的某些特定步骤
• 子类重写父类的一些方法
• 定义一套流程模板，根据需要实现模板中的操作
• 优点：
  • 封装了不可变的部分，扩展了可变的部分
  • 在父类中提取了公共的部分代码，便于代码复用
  • 部分方法由子类实现，因此子类可以 通过扩展方式增加相应的功能，符合开闭原则
• 缺点
  • 对于不同的实现，就要定一个子类，导致类的个数增加，间接地增加了系统实现的复杂度
  • 父类中的抽象方法由子类实现，子类执
  • 由于继承关系自身的缺点，如果父类添加新的抽象方法，则所有子类都要改一遍。

// 抽象类
class AbstractClass {
public:
    virtual  void method() {
        specificMethod1();
        specificMethod2();
    }
    
    virtual void specificMethod1() {
        
    }
    
    virtual void specificMethod2() {
        
    }
};

// 具体子类
class ConcreteClass: public AbstractClass {
    void specificMethod1() override {
        printf("specificMethod1");
    }
    
    void specificMethod2() override {
        printf("specificMethod2");
    }
};

策略模式

• 定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户
• 封装不同的算法，算法之间能互相替换
• 角色
  • 抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。
  • 具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现。
  • 环境（Context）类：持有一个策略类的引用，最终给客户端调用
• 优点
  • 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句，如 if...else 语句、switch...case 语句。
  • 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
  • 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
  • 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
  • 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。

// 抽象策略类
struct Strategy {
    virtual void strategyMethod() = 0;
};

// 具体策略A
struct ConcreteStrayA: public Strategy {
    
    void strategyMethod() override {
        
    }
};

// 具体策略B
struct ConcreteStrayB: public Strategy {
    
    void strategyMethod() override {
        
    }
};

// 环境类
struct Context {
private:
    Strategy *m_strategy = nullptr;
public:
    void strategyMethod() {
        m_strategy->strategyMethod();
    }
};

命令模式

• 定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开
• 角色
  • 抽象命令类：声明执行命令的接口
  • 具体命令类：抽象命令类的具体实现，包含接收者对象，并通过调用接收者的功能来完成命令要执行的操作
  • 实现者：执行命令相关的操作。是具体命令对对象业务的真正实现者
  • 调用者：是请求的发送者，它通常拥有很多的命令对象，并通过访问命令对象执行请求，它不直接访问接收者
• 解耦请求和处理

• 案例：遥控器

  
  

/**
 【例1】用命令模式实现客户去餐馆吃早餐的实例。
 
 分析：客户去餐馆可选择的早餐有肠粉、河粉和馄饨等，客户可向服务员选择以上早餐中的若干种，服务员将客户的请求交给相关的厨师去做。这里的点早餐相当于“命令”，服务员相当于“调用者”，厨师相当于“接收者”，所以用命令模式实现比较合适。
 首先，定义一个早餐类（Breakfast），它是抽象命令类，有抽象方法 cooking()，说明要做什么；
 再定义其子类肠粉类（ChangFen）、馄饨类（HunTun）和河粉类（HeFen），它们是具体命令类，实现早餐类的 cooking() 方法，但它们不会具体做，而是交给具体的厨师去做；
 具体厨师类有肠粉厨师（ChangFenChef）、馄饨厨师（HunTunChef）和河粉厨师（HeFenChef），他们是命令的接收者。
 */

// 抽象命令
class BreakFast {
    
public:
    virtual void cooking() = 0;
};
// 接收者
class ChanfenChief {
        
    
public:
    void cooking() {
        
    }
};

// 具体命令
class Chanfen: public BreakFast {
private:
    ChanfenChief *m_reciever = nullptr;
public:
    void cooking() override {
        m_reciever->cooking();
    }
};

// 接收者
class HundunChief {

public:
    void cooking() {
        
    }
};

// 具体命令
class Hundun: public BreakFast {
private:
    HundunChief *m_reciever = nullptr;
public:
    void cooking() override {
        m_reciever->cooking();
    }
};

/// 调用者：执行命令
class Waiter {
    Hundun * m_hundun = nullptr;
    Chanfen * m_chanfen = nullptr;
    
public:
    void chooseHundun() {
        m_hundun->cooking();
    }
    
    void chooseChanfen() {
        m_chanfen->cooking();
    }
};

责任链模式（职责链模式）

• 为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。
• 处理好自己分内的事，如果处理不好，则交由给下一位处理

• 案例：请假

  
  
  

public class ChainOfResponsibilityPattern {
    public static void main(String[] args) {
        //组装责任链
        Handler handler1 = new ConcreteHandler1();
        Handler handler2 = new ConcreteHandler2();
        handler1.setNext(handler2);
        //提交请求
        handler1.handleRequest("two");
    }
}
//抽象处理者角色
abstract class Handler {
    private Handler next;
    public void setNext(Handler next) {
        this.next = next;
    }
    public Handler getNext() {
        return next;
    }
    //处理请求的方法
    public abstract void handleRequest(String request);
}
//具体处理者角色1
class ConcreteHandler1 extends Handler {
    public void handleRequest(String request) {
        if (request.equals("one")) {
            System.out.println("具体处理者1负责处理该请求！");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(request);
            } else {
                System.out.println("没有人处理该请求！");
            }
        }
    }
}
//具体处理者角色2
class ConcreteHandler2 extends Handler {
    public void handleRequest(String request) {
        if (request.equals("two")) {
            System.out.println("具体处理者2负责处理该请求！");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(request);
            } else {
                System.out.println("没有人处理该请求！");
            }
        }
    }
}
程序运行结果如下：
具体处理者2负责处理该请求！
在上面代码中，我们把消息硬编码为 String 类型，而在真实业务中，消息是具备多样性的，可以是 int、String 或者自定义类型。因此，在上面代码的基础上，可以对消息类型进行抽象 Request，增强了消息的兼容性。
模式的应用实例
【例1】用责任链模式设计一个请假条审批模块。

分析：假如规定学生请假小于或等于 2 天，班主任可以批准；小于或等于 7 天，系主任可以批准；小于或等于 10 天，院长可以批准；其他情况不予批准；这个实例适合使用职责链模式实现。

首先，定义一个领导类（Leader），它是抽象处理者，包含了一个指向下一位领导的指针 next 和一个处理假条的抽象处理方法 handleRequest(int LeaveDays)；然后，定义班主任类（ClassAdviser）、系主任类（DepartmentHead）和院长类（Dean），它们是抽象处理者的子类，是具体处理者，必须根据自己的权力去实现父类的 handleRequest(int LeaveDays) 方法，如果无权处理就将假条交给下一位具体处理者，直到最后；客户类负责创建处理链，并将假条交给链头的具体处理者（班主任）。图 3 所示是其结构图。

请假条审批模块的结构图
图3 请假条审批模块的结构图

程序代码如下：
纯文本复制
package chainOfResponsibility;
public class LeaveApprovalTest {
    public static void main(String[] args) {
        //组装责任链
        Leader teacher1 = new ClassAdviser();
        Leader teacher2 = new DepartmentHead();
        Leader teacher3 = new Dean();
        //Leader teacher4=new DeanOfStudies();
        teacher1.setNext(teacher2);
        teacher2.setNext(teacher3);
        //teacher3.setNext(teacher4);
        //提交请求
        teacher1.handleRequest(8);
    }
}
//抽象处理者：领导类
abstract class Leader {
    private Leader next;
    public void setNext(Leader next) {
        this.next = next;
    }
    public Leader getNext() {
        return next;
    }
    //处理请求的方法
    public abstract void handleRequest(int LeaveDays);
}
//具体处理者1：班主任类
class ClassAdviser extends Leader {
    public void handleRequest(int LeaveDays) {
        if (LeaveDays <= 2) {
            System.out.println("班主任批准您请假" + LeaveDays + "天。");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(LeaveDays);
            } else {
                System.out.println("请假天数太多，没有人批准该假条！");
            }
        }
    }
}
//具体处理者2：系主任类
class DepartmentHead extends Leader {
    public void handleRequest(int LeaveDays) {
        if (LeaveDays <= 7) {
            System.out.println("系主任批准您请假" + LeaveDays + "天。");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(LeaveDays);
            } else {
                System.out.println("请假天数太多，没有人批准该假条！");
            }
        }
    }
}
//具体处理者3：院长类
class Dean extends Leader {
    public void handleRequest(int LeaveDays) {
        if (LeaveDays <= 10) {
            System.out.println("院长批准您请假" + LeaveDays + "天。");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(LeaveDays);
            } else {
                System.out.println("请假天数太多，没有人批准该假条！");
            }
        }
    }
}
//具体处理者4：教务处长类
class DeanOfStudies extends Leader {
    public void handleRequest(int LeaveDays) {
        if (LeaveDays <= 20) {
            System.out.println("教务处长批准您请假" + LeaveDays + "天。");
        } else {
            if (getNext() != null) {
                getNext().handleRequest(LeaveDays);
            } else {
                System.out.println("请假天数太多，没有人批准该假条！");
            }
        }
    }
}

状态模式

• 对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为
• 环境类（Context）角色：也称为上下文，它定义了客户端需要的接口，内部维护一个当前状态，并负责具体状态的切换。
  抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为，可以有一个或多个行为。
  具体状态（Concrete State）角色：实现抽象状态所对应的行为，并且在需要的情况下进行状态切换。
• 根据不同的状态做出不同的行为
• 经典案例：订单状态跟踪

image.png

public class ScoreStateTest {
    public static void main(String[] args) {
        ThreadContext context = new ThreadContext();
        context.start();
        context.getCPU();
        context.suspend();
        context.resume();
        context.getCPU();
        context.stop();
    }
}

//环境类
class ThreadContext {
    private ThreadState state;

    ThreadContext() {
        state = new New();
    }

    public void setState(ThreadState state) {
        this.state = state;
    }

    public ThreadState getState() {
        return state;
    }

    public void start() {
        ((New) state).start(this);
    }

    public void getCPU() {
        ((Runnable) state).getCPU(this);
    }

    public void suspend() {
        ((Running) state).suspend(this);
    }

    public void stop() {
        ((Running) state).stop(this);
    }

    public void resume() {
        ((Blocked) state).resume(this);
    }
}

//抽象状态类：线程状态
abstract class ThreadState {
    protected String stateName; //状态名
}

//具体状态类：新建状态
class New extends ThreadState {
    public New() {
        stateName = "新建状态";
        System.out.println("当前线程处于：新建状态.");
    }

    public void start(ThreadContext hj) {
        System.out.print("调用start()方法-->");
        if (stateName.equals("新建状态")) {
            hj.setState(new Runnable());
        } else {
            System.out.println("当前线程不是新建状态，不能调用start()方法.");
        }
    }
}

//具体状态类：就绪状态
class Runnable extends ThreadState {
    public Runnable() {
        stateName = "就绪状态";
        System.out.println("当前线程处于：就绪状态.");
    }

    public void getCPU(ThreadContext hj) {
        System.out.print("获得CPU时间-->");
        if (stateName.equals("就绪状态")) {
            hj.setState(new Running());
        } else {
            System.out.println("当前线程不是就绪状态，不能获取CPU.");
        }
    }
}

//具体状态类：运行状态
class Running extends ThreadState {
    public Running() {
        stateName = "运行状态";
        System.out.println("当前线程处于：运行状态.");
    }

    public void suspend(ThreadContext hj) {
        System.out.print("调用suspend()方法-->");
        if (stateName.equals("运行状态")) {
            hj.setState(new Blocked());
        } else {
            System.out.println("当前线程不是运行状态，不能调用suspend()方法.");
        }
    }

    public void stop(ThreadContext hj) {
        System.out.print("调用stop()方法-->");
        if (stateName.equals("运行状态")) {
            hj.setState(new Dead());
        } else {
            System.out.println("当前线程不是运行状态，不能调用stop()方法.");
        }
    }
}

//具体状态类：阻塞状态
class Blocked extends ThreadState {
    public Blocked() {
        stateName = "阻塞状态";
        System.out.println("当前线程处于：阻塞状态.");
    }

    public void resume(ThreadContext hj) {
        System.out.print("调用resume()方法-->");
        if (stateName.equals("阻塞状态")) {
            hj.setState(new Runnable());
        } else {
            System.out.println("当前线程不是阻塞状态，不能调用resume()方法.");
        }
    }
}

//具体状态类：死亡状态
class Dead extends ThreadState {
    public Dead() {
        stateName = "死亡状态";
        System.out.println("当前线程处于：死亡状态.");
    }
}

观察者模式

• 定义：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。
• 状态发生改变时通知观察者，一对多的关系
• 解耦观察者与被观察者
• 抽象主题（Subject）角色：也叫抽象目标类，它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法。
• 具体主题（Concrete Subject）角色：也叫具体目标类，它实现抽象目标中的通知方法，当具体主题的内部状态发生改变时，通知所有注册过的观察者对象。
• 抽象观察者（Observer）角色：它是一个抽象类或接口，它包含了一个更新自己的抽象方法，当接到具体主题的更改通知时被调用。
• 具体观察者（Concrete Observer）角色：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。
• 优点：降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。符合依赖倒置原则。
  • 目标与观察者之间建立了一套触发机制。
• 缺点： 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
  • 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

/**
 【例1】利用观察者模式设计一个程序，分析“人民币汇率”的升值或贬值对进口公司进口产品成本或出口公司的出口产品收入以及公司利润率的影响。

 分析：当“人民币汇率”升值时，进口公司的进口产品成本降低且利润率提升，出口公司的出口产品收入降低且利润率降低；当“人民币汇率”贬值时，进口公司的进口产品成本提升且利润率降低，出口公司的出口产品收入提升且利润率提升
 */
// 抽象观察者
struct Company {
    virtual void response(int number) = 0;
};

struct Rate {
protected:
    vector<Company*> companys;
    
public:
    
    void add(Company *company) {
        companys.push_back(company);
    }
    
    void remove(Company *company) {
        companys.push_back(company);
    }
    
    // 通知方法
    virtual void change(int number) = 0;
};

struct RMBRate: public Rate {
    
    void change(int number) override {
        for (Company * company : companys) {
            company->response(number);
        }
    }
};

// 具体观察者
struct ImportCompany: public Company {
    
    void response(int number) override {
        
    }
};

// 具体观察者
struct ExportCompany: public Company {
    
    void response(int number) override {
        
    }
};

class ObserverTest {
  
    void test() {
        ImportCompany *icmp = new ImportCompany();
        ExportCompany *ecmp = new ExportCompany();
        RMBRate * rate = new RMBRate();
        rate->add(icmp);
        rate->add(ecmp);
        rate->change(3);
    }
};

中介者（Mediator）模式：

• 定义一个中介对象来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互。中介者模式又叫调停模式，它是迪米特法则的典型应用。最经典的案例MVC
• 统一管理网状资源
• 优点
  • 类之间各司其职，符合迪米特法则。
  • 降低了对象之间的耦合性，使得对象易于独立地被复用。
  • 将对象间的一对多关联转变为一对一的关联，提高系统的灵活性，使得系统易于维护和扩展。
• 缺点
  • 中介者模式将原本多个对象直接的相互依赖变成了中介者和多个同事类的依赖关系。当同事类越多时，中介者就会越臃肿，变得复杂且难以维护。
• 角色
  • 抽象中介者（Mediator）角色：它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法。
  • 具体中介者（Concrete Mediator）角色：实现中介者接口，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系，因此它依赖于同事角色。
  • 抽象同事类（Colleague）角色：定义同事类的接口，保存中介者对象，提供同事对象交互的抽象方法，实现所有相互影响的同事类的公共功能。

  • 具体同事类（Concrete Colleague）角色：是抽象同事类的实现者，当需要与其他同事对象交互时，由中介者对象负责后续的交互。

    
    

package net.biancheng.c.mediator;

import java.util.*;

public class MediatorPattern {
    public static void main(String[] args) {
        Mediator md = new ConcreteMediator();
        Colleague c1, c2;
        c1 = new ConcreteColleague1();
        c2 = new ConcreteColleague2();
        md.register(c1);
        md.register(c2);
        c1.send();
        System.out.println("-------------");
        c2.send();
    }
}

//抽象中介者
abstract class Mediator {
    public abstract void register(Colleague colleague);

    public abstract void relay(Colleague cl); //转发
}

//具体中介者
class ConcreteMediator extends Mediator {
    private List<Colleague> colleagues = new ArrayList<Colleague>();

    public void register(Colleague colleague) {
        if (!colleagues.contains(colleague)) {
            colleagues.add(colleague);
            colleague.setMedium(this);
        }
    }

    public void relay(Colleague cl) {
        for (Colleague ob : colleagues) {
            if (!ob.equals(cl)) {
                ((Colleague) ob).receive();
            }
        }
    }
}

//抽象同事类
abstract class Colleague {
    protected Mediator mediator;

    public void setMedium(Mediator mediator) {
        this.mediator = mediator;
    }

    public abstract void receive();

    public abstract void send();
}

//具体同事类
class ConcreteColleague1 extends Colleague {
    public void receive() {
        System.out.println("具体同事类1收到请求。");
    }

    public void send() {
        System.out.println("具体同事类1发出请求。");
        mediator.relay(this); //请中介者转发
    }
}

//具体同事类
class ConcreteColleague2 extends Colleague {
    public void receive() {
        System.out.println("具体同事类2收到请求。");
    }

    public void send() {
        System.out.println("具体同事类2发出请求。");
        mediator.relay(this); //请中介者转发
    }
}

迭代器（Iterator）模式

• 定义：提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。迭代器模式是一种对象行为型模式，

• 统一对集合的访问方式

• 优点

  • 访问一个聚合对象的内容而无须暴露它的内部表示。
  • 遍历任务交由迭代器完成，这简化了聚合类。
  • 它支持以不同方式遍历一个聚合，甚至可以自定义迭代器的子类以支持新的遍历。
  • 增加新的聚合类和迭代器类都很方便，无须修改原有代码。
  • 封装性良好，为遍历不同的聚合结构提供一个统一的接口。

• 缺点：增加了类的个数

public class IteratorPattern {
    public static void main(String[] args) {
        Aggregate ag = new ConcreteAggregate();
        ag.add("中山大学");
        ag.add("华南理工");
        ag.add("韶关学院");
        System.out.print("聚合的内容有：");
        Iterator it = ag.getIterator();
        while (it.hasNext()) {
            Object ob = it.next();
            System.out.print(ob.toString() + "\t");
        }
        Object ob = it.first();
        System.out.println("\nFirst：" + ob.toString());
    }
}
//抽象聚合
interface Aggregate {
    public void add(Object obj);
    public void remove(Object obj);
    public Iterator getIterator();
}
//具体聚合
class ConcreteAggregate implements Aggregate {
    private List<Object> list = new ArrayList<Object>();
    public void add(Object obj) {
        list.add(obj);
    }
    public void remove(Object obj) {
        list.remove(obj);
    }
    public Iterator getIterator() {
        return (new ConcreteIterator(list));
    }
}
//抽象迭代器
interface Iterator {
    Object first();
    Object next();
    boolean hasNext();
}
//具体迭代器
class ConcreteIterator implements Iterator {
    private List<Object> list = null;
    private int index = -1;
    public ConcreteIterator(List<Object> list) {
        this.list = list;
    }
    public boolean hasNext() {
        if (index < list.size() - 1) {
            return true;
        } else {
            return false;
        }
    }
    public Object first() {
        index = 0;
        Object obj = list.get(index);
        ;
        return obj;
    }
    public Object next() {
        Object obj = null;
        if (this.hasNext()) {
            obj = list.get(++index);
        }
        return obj;
    }
}

访问者（Visitor）模式

• 定义：将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离

• 解耦数据结构和数据操作,类似于C++中函数指针。lamlda表达式，Swift中的闭包

• 访问者（Visitor）模式是一种对象行为型模式，

• 优点

  • 扩展性好。能够在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
  • 复用性好。可以通过访问者来定义整个对象结构通用的功能，从而 提高系统的复用程度。
  • 灵活性好。访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可相对自由地演化而不影响系统的数据结构。
  • 符合单一职责原则。访问者模式把相关的行为封装在一起，构成一个访问者，使每一个访问者的功能都比较单一。

• 缺点

  • 增加新的元素类很困难。在访问者模式中，每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，这违背了“开闭原则”。
  • 破坏封装。访问者模式中具体元素对访问者公布细节，这破坏了对象的封装性。
  • 违反了依赖倒置原则。访问者模式依赖了具体类，而没有依赖抽象类。

package net.biancheng.c.visitor;

import java.util.*;

public class VisitorPattern {
    public static void main(String[] args) {
        ObjectStructure os = new ObjectStructure();
        os.add(new ConcreteElementA());
        os.add(new ConcreteElementB());
        Visitor visitor = new ConcreteVisitorA();
        os.accept(visitor);
        System.out.println("------------------------");
        visitor = new ConcreteVisitorB();
        os.accept(visitor);
    }
}

//抽象访问者
interface Visitor {
    void visit(ConcreteElementA element);

    void visit(ConcreteElementB element);
}

//具体访问者A类
class ConcreteVisitorA implements Visitor {
    public void visit(ConcreteElementA element) {
        System.out.println("具体访问者A访问-->" + element.operationA());
    }

    public void visit(ConcreteElementB element) {
        System.out.println("具体访问者A访问-->" + element.operationB());
    }
}

//具体访问者B类
class ConcreteVisitorB implements Visitor {
    public void visit(ConcreteElementA element) {
        System.out.println("具体访问者B访问-->" + element.operationA());
    }

    public void visit(ConcreteElementB element) {
        System.out.println("具体访问者B访问-->" + element.operationB());
    }
}

//抽象元素类
interface Element {
    void accept(Visitor visitor);
}

//具体元素A类
class ConcreteElementA implements Element {
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }

    public String operationA() {
        return "具体元素A的操作。";
    }
}

//具体元素B类
class ConcreteElementB implements Element {
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }

    public String operationB() {
        return "具体元素B的操作。";
    }
}

//对象结构角色
class ObjectStructure {
    private List<Element> list = new ArrayList<Element>();

    public void accept(Visitor visitor) {
        Iterator<Element> i = list.iterator();
        while (i.hasNext()) {
            ((Element) i.next()).accept(visitor);
        }
    }

    public void add(Element element) {
        list.add(element);
    }

    public void remove(Element element) {
        list.remove(element);
    }
}

备忘录（Memento）模式

• 定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后当需要时能将该对象恢复到原先保存的状态。该模式又叫快照模式。

• 备忘录模式是一种对象行为型模式

• 优点

  • 提供了一种可以恢复状态的机制。当用户需要时能够比较方便地将数据恢复到某个历史的状态。
  • 实现了内部状态的封装。除了创建它的发起人之外，其他对象都不能够访问这些状态信息。
  • 简化了发起人类。发起人不需要管理和保存其内部状态的各个备份，所有状态信息都保存在备忘录中，并由管理者进行管理，这符合单一职责原则。

• 备份、后悔机制

• 缺点：资源消耗大。如果要保存的内部状态信息过多或者特别频繁，将会占用比较大的内存资源。

• 角色

  • 发起人（Originator）角色：记录当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能，它可以访问备忘录里的所有信息。
  • 备忘录（Memento）角色：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。

  • 管理者（Caretaker）角色：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。

    
    

package net.biancheng.c.memento;

public class MementoPattern {
    public static void main(String[] args) {
        Originator or = new Originator();
        Caretaker cr = new Caretaker();
        or.setState("S0");
        System.out.println("初始状态:" + or.getState());
        cr.setMemento(or.createMemento()); //保存状态
        or.setState("S1");
        System.out.println("新的状态:" + or.getState());
        or.restoreMemento(cr.getMemento()); //恢复状态
        System.out.println("恢复状态:" + or.getState());
    }
}

//备忘录
class Memento {
    private String state;

    public Memento(String state) {
        this.state = state;
    }

    public void setState(String state) {
        this.state = state;
    }

    public String getState() {
        return state;
    }
}

//发起人
class Originator {
    private String state;

    public void setState(String state) {
        this.state = state;
    }

    public String getState() {
        return state;
    }

    public Memento createMemento() {
        return new Memento(state);
    }

    public void restoreMemento(Memento m) {
        this.setState(m.getState());
    }
}

//管理者
class Caretaker {
    private Memento memento;

    public void setMemento(Memento m) {
        memento = m;
    }

    public Memento getMemento() {
        return memento;
    }
}

解释器（Interpreter）模式

• 定义：给分析对象定义一个语言，并定义该语言的文法表示，再设计一个解析器来解释语言中的句子。也就是说，用编译语言的方式来分析应用中的实例。这种模式实现了文法表达式处理的接口，该接口解释一个特定的上下文。
• 实现特定语法解析
• 这里提到的文法和句子的概念同编译原理中的描述相同，“文法”指语言的语法规则，而“句子”是语言集中的元素。例如，汉语中的句子有很多，“我是中国人”是其中的一个句子，可以用一棵语法树来直观地描述语言中的句子。

解释器模式是一种类行为型模式

• 优点：

  • 扩展性好。由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。
  • 容易实现。在语法树中的每个表达式节点类都是相似的，所以实现其文法较为容易。

• 缺点

  • 执行效率较低。解释器模式中通常使用大量的循环和递归调用，当要解释的句子较复杂时，其运行速度很慢，且代码的调试过程也比较麻烦。
  • 会引起类膨胀。解释器模式中的每条规则至少需要定义一个类，当包含的文法规则很多时，类的个数将急剧增加，导致系统难以管理与维护。
  • 可应用的场景比较少。在软件开发中，需要定义语言文法的应用实例非常少，所以这种模式很少被使用到。

• 角色

  • 抽象表达式（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
  • 终结符表达式（Terminal Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
  • 非终结符表达式（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
  • 环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
  • 客户端（Client）：主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。

委派模式（Delegate Pattern）

• 允许对象组合实现与继承相同的代码重用，负责任务的调用和分配
• 只对结果负责
• 经典案例：tableview的代理实现
• 角色
  • 抽象委托对象
  • 具体委托对象
  • 委托发起对象