C++设计模式

最新推荐文章于 2023-06-15 19:01:54 发布

嘻嘻西西兮兮

最新推荐文章于 2023-06-15 19:01:54 发布

阅读量700

点赞数

分类专栏： C++ 文章标签： c++ 数据库

本文链接：https://blog.csdn.net/weixin_43684773/article/details/121625701

版权

C++ 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1. 设计模式简介

Shape1（分解）
Shape2（抽象）
基类最好要有虚的析构函数。
所有继承最好都要用public的继承。
多态性->指针
第一种如果要变更，需要在所有涉及的地方修改。
第二种如果要变更，如果使用工厂模式，只需要增加一个子类。重用性得到了很高的提升

2. 面向对象的设计原则

2.1 重新认识面向对象

理解隔离变化
- 从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。
各司其职
- 从微观层面来看，面向对象的方式更强调各类的“责任”
- 适用于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责
对象是什么？
- 从语言实现层面来看，对象封装了代码和数据。
- 从规格层面讲，对象是一系列可被使用的公共接口。
- 从概念层面讲，对象是某种拥有责任的抽象。

2.2 面向对象设计原则

2.2.1 依赖倒置原则（DIP）

高层模块（稳定）不应依赖于低层模块（变化），二者应该依赖于抽象（稳定）。
- MainForm（依赖）->Line Rect
抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。
- MainForm（依赖）->Shape<-（依赖）Line Rect
实现了变化的隔离

2.2.2 开放封闭原则（OCP）

对扩展开放，对更改封闭。
类模块应该是可扩展的，但是不可修改。
- 增加一些东西来应对变化，不需要修改原来的代码

2.2.3 单一职责原则（SRP）

一个类应该仅有一个引起它变化的原因。
变化的方向隐含着类的责任。

2.2.4 Liskov替换原则（LSP）

子类必须能够替换它们的基类==（IS-A）==。
继承表达类型抽象。

2.2.5 接口隔离原则（ISP）

不应该强迫客户依赖它们不用的方法。
接口应该小而完备。
一旦产生依赖，就必须保持稳定。

2.2.6 优先使用对象组合，而不是类继承

类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。
继承在某种程度上破坏了封装性，子类父类耦合度高。
而对象组合则要求被组合的对象具有良好定义的接口耦合度低。

2.2.7 封装变化点

使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响从而实现层次间的松耦合。
封装更高层次的理解应该是封装变化点，一侧变化一侧稳定。

2.2.8 针对接口编程，而不是针对实现变成

不将变量类型声明为某个特定的具体类，而是声明为某个接口。
客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。

2.3 面向接口设计

产业强盛的标志：接口标准化
分工协作，通过分工实现复用性。

2.4 将设计原则提升为设计经验

设计习语 Design Idioms
Design Idioms 描述与特定编程语言相关的低层模式，技巧，惯用法。
设计模式 Design Patterns
Design Patterns 主要描述的是“类与相互通信对象之间的组织关系，包括它们的角色、职责、协作方式等方面。
架构模式 Architectural Patterns
Architectural Patterns 描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，职责，以及如何组织它们之间关系的规则。

3. 模式方法 Template Method

3.1 GOF-23 模式分类

从目的来看：
- 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。
- 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。
- 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。
从范围来看：
- 类模式处理类与子类的静态关系。（集成）
- 对象模式处理对象间的动态关系。（组合）

3.2 从封装变化角度对模式分类

组件协作：
Template Method
Strategy
Observer/Event
单一职责：
Decorator
Bridge
对象创建：
Factory Method
Abstract Factory
Prototype
Builder
对象性能：
Singleton
Flyweight
接口隔离：
Facade
Proxy
Mediator
Adapter
状态变化：
Memento
State
数据结构：
Composite
Iterator
Chain of Responsibility
行为变化：
Command
Visitor
领域问题：
Interpreter

3.3 重构获得模式 Refactoring to Patterns

面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指的是那些可以满足”应对变化，提高复用”的设计。
现代软件设计的特征是“需求的频繁变化”。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”。“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

在这里插入图片描述

3.4 重构关键技法

静态 → 动态
早绑定 → 晚绑定
继承 → 组合
编译时依赖 → 运行时依赖
紧耦合 → 松耦合

是从不同角度谈一个问题

3.5 “组件协作”模式

现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，使二者之间协作时常用的模式。
典型模式
- Template Method
- Strategy
- Observer / Event

4. 模板方法

4.1 动机（Motivation）

在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。
如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？

基类一定要写虚的析构函数

结构化软件设计流程：
面向对象软件设计流程
早绑定与晚绑定

4.2 常见方式

将过程写到库中，过程中留有虚函数，在复用时定义虚函数。
纵向的灵活性。

4.3 模式定义

定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template Method 使得子类可以不改变（复用）一个算法的结构即可重定义（override 重写）该算法的某些特定步骤。

绝大多数设计模式的特点：稳定中带有变化！
- 将稳定的东西写成非虚函数
- 变化的东西写成虚函数（纯虚函数）

在这里插入图片描述
设计模式最大的作用是在变化和稳定之间寻找分离的来隔离他们，从而来管理变化。如果一个程序全部是稳定的或者没有一个稳定的地方，那么这个设计模式也就没有了意义！正常的软件体系结构一定是既有稳定的，也有变化的！

稳定是相对稳定，变化是相对不稳定！

4.4 结构

在这里插入图片描述
TemplateMethod() 稳定
PrimitiveOperation() 变化
每次遇到Lib，都要知道哪些是稳定的部分，哪些是不稳定的部分。

4.5 要点总结

Template Method 模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点（继承+多态），是代码复用方面的基本实现结构。
除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是 Template Method 的典型应用。
在具体实现方面，被 Template Method 调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为 protected 方法（这些方法单独作为一个方法让外界使用的意义不大）。
虚函数本质上就是虚函数表中挂着一个函数指针

5. 策略模式

5.1 动机（Motivation）

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。
如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？
应该尽可能用扩展的方式解决问题，而不是直接修改源代码。
多态性就要求指针必须可以指向多种类，不是一个确定的类，引用不可以。

5.2 代码

class TaxStrategy{
public:
    virtual double Calculate(const Context& context)=0;
    virtual ~TaxStrategy(){}
};




class CNTax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};

class USTax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};

class DETax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};



//扩展
//*********************************
class FRTax : public TaxStrategy{
public:
	virtual double Calculate(const Context& context){
		//.........
	}
};




class SalesOrder{
private:
    TaxStrategy* strategy;

public:
    SalesOrder(StrategyFactory* strategyFactory){
        this->strategy = strategyFactory->NewStrategy(); // 工厂
    }
    ~SalesOrder(){
        delete this->strategy;
    }

    public double CalculateTax(){
        //...
        Context context();
        
        double val = 
            strategy->Calculate(context); // 多态调用
        //...
    }
    
};

5.3 模式定义

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化==（扩展，子类化）==。

5.4 常见方式

构建一个基类，多个子类。
构建一个类，引用这个基类，并在函数中由其他参数决定使用哪个子类。
横向的自由度。
在这里插入图片描述
Context和Strategy稳定
ConcreteStrategy变化

5.5 要点总结

Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
Strategy 模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条判断语句的代码通常都需要Strategy模式。（if-else是结构化时代分而治之的情况，要思考以后是否会有变化，如果if-else是绝对不变的情况那么可以使用if-else的情况）
如果Strategy 对象没有实例变量，那么各个上下文可以共享同一个Strategy 对象，从而节省对象开销。

6. Observer 观察者模式

6.1 动机（Motivation）

在软件构架过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
*使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
C++一般不推荐多继承，但是可以选择有主继承，其他都是接口。

6.2 代码

观察者：IProgress对于每一个观察者有不同的实现，每个特定的观察者继承IProgress类实现观察者的具体代码。观察者指针作为一个类的数据被使用，在类中完成观察者指针代码的调用。
如果用原来的写法，就需要每次多传一个指针

6.2.1 MainForm.cpp

class MainForm : public Form, public IProgress
{
	TextBox* txtFilePath;
	TextBox* txtFileNumber;

	ProgressBar* progressBar;

public:
	void Button1_Click(){

		string filePath = txtFilePath->getText();
		int number = atoi(txtFileNumber->getText().c_str());

		ConsoleNotifier cn;

		FileSplitter splitter(filePath, number);

		splitter.addIProgress(this); // 订阅通知
		splitter.addIProgress(&cn)； // 订阅通知

		splitter.split();

		splitter.removeIProgress(this);

	}

	virtual void DoProgress(float value){
		progressBar->setValue(value);
	}
};

class ConsoleNotifier : public IProgress {
public:
	virtual void DoProgress(float value){
		cout << ".";
	}
};

6.2.2 FileSplitter.cpp

class IProgress{
public:
	virtual void DoProgress(float value)=0;
	virtual ~IProgress(){}
};


class FileSplitter
{
	string m_filePath;
	int m_fileNumber;

	List<IProgress*>  m_iprogressList; // 抽象通知机制，支持多个观察者
	
public:
	FileSplitter(const string& filePath, int fileNumber) :
		m_filePath(filePath), 
		m_fileNumber(fileNumber){

	}


	void split(){

		//1.读取大文件

		//2.分批次向小文件中写入
		for (int i = 0; i < m_fileNumber; i++){
			//...

			float progressValue = m_fileNumber;
			progressValue = (i + 1) / progressValue;
			onProgress(progressValue);  // 发送通知
		}

	}


	void addIProgress(IProgress* iprogress){
		m_iprogressList.push_back(iprogress);
	}

	void removeIProgress(IProgress* iprogress){
		m_iprogressList.remove(iprogress);
	}


protected:
	virtual void onProgress(float value){
		
		List<IProgress*>::iterator itor=m_iprogressList.begin();

		while (itor != m_iprogressList.end() )
			(*itor)->DoProgress(value); // 更新进度条
			itor++;
		}
	}
};

6.3 结构

在这里插入图片描述

6.4 要点总结

使用面向对象的抽象，Observer 模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达至松耦合。
目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。
观察者自己决定是否需要订阅通知，目标对象对此一无所知。
Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

7. Decorator 装饰模式

在软件组件的设计中，如果职责划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
典型模式
- Decorator
- Bridge

7.1 动机（Motivation）

在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降为最低？
针对不同的流创建不同的子类去继承基类，但是不同流需要进行一些加密操作，加密操作可能是针对不同的流是一样的，就会造成相同代码的重复膨胀（代码冗余）
一般结构
绝大多数设计模式的真谛：编译时让其复用，需求的变化都扔到运行时使用多态的方式支持变化，但是运行时多态破坏了现代芯片的cache友好，分支预测等代码加速的特性。
装饰结构

7.2 代码

版本1

// 业务操作
class Stream{

public：
    virtual char Read(int number)=0;
    virtual void Seek(int position)=0;
    virtual void Write(char data)=0;
    
    virtual ~Stream(){}
};

// 主体类
class FileStream: public Stream{
public:
    virtual char Read(int number){
        // 读文件流
    }
    virtual void Seek(int position){
        // 定位文件流
    }
    virtual void Write(char data){
        // 写文件流
    }

};

class NetworkStream :public Stream{
public:
    virtual char Read(int number){
        // 读网络流
    }
    virtual void Seek(int position){
        // 定位网络流
    }
    virtual void Write(char data){
        // 写网络流
    }
    
};

class MemoryStream :public Stream{
public:
    virtual char Read(int number){
        // 读内存流
    }
    virtual void Seek(int position){
        // 定位内存流
    }
    virtual void Write(char data){
        // 写内存流
    }
    
};

// 扩展操作（加密操作）
class CryptoStream: public Stream {
    
    Stream* stream;//...

public:
    CryptoStream(Stream* stm):stream(stm){
    
    }
    virtual char Read(int number){
        // 额外的加密操作...
        stream->Read(number);// 读文件流
    }
    virtual void Seek(int position){
        // 额外的加密操作...
        stream::Seek(position);// 定位文件流
        // 额外的加密操作...
    }
    virtual void Write(byte data){
        // 额外的加密操作...
        stream::Write(data);// 写文件流
        // 额外的加密操作...
    }
};


// 缓存操作
class BufferedStream : public Stream{
    
    Stream* stream;//...
    
public:
    BufferedStream(Stream* stm):stream(stm){
        
    }
    //...
};


void Process(){
    //运行时装配
    FileStream* s1=new FileStream();
    
    CryptoStream* s2=new CryptoStream(s1);
    
    BufferedStream* s3=new BufferedStream(s1);
    
    BufferedStream* s4=new BufferedStream(s2);
}

版本2

//业务操作
class Stream{

public：
    virtual char Read(int number)=0;
    virtual void Seek(int position)=0;
    virtual void Write(char data)=0;
    
    virtual ~Stream(){}
};

//主体类
class FileStream: public Stream{
public:
    virtual char Read(int number){
        //读文件流
    }
    virtual void Seek(int position){
        //定位文件流
    }
    virtual void Write(char data){
        //写文件流
    }

};

class NetworkStream :public Stream{
public:
    virtual char Read(int number){
        //读网络流
    }
    virtual void Seek(int position){
        //定位网络流
    }
    virtual void Write(char data){
        //写网络流
    }
    
};

class MemoryStream :public Stream{
public:
    virtual char Read(int number){
        //读内存流
    }
    virtual void Seek(int position){
        //定位内存流
    }
    virtual void Write(char data){
        //写内存流
    }
    
};

//扩展操作
DecoratorStream: public Stream{
protected:
    Stream* stream;//...
    
    DecoratorStream(Stream * stm):stream(stm){
    
    }
    
};

class CryptoStream: public DecoratorStream {
public:
    CryptoStream(Stream* stm):DecoratorStream(stm){ // 注意这个继承的写法
    }
    
    virtual char Read(int number){ 
        //额外的加密操作...
        stream->Read(number);//读文件流
    }
    virtual void Seek(int position){
        //额外的加密操作...
        stream::Seek(position);//定位文件流
        //额外的加密操作...
    }
    virtual void Write(byte data){
        //额外的加密操作...
        stream::Write(data);//写文件流
        //额外的加密操作...
    }
};



class BufferedStream : public DecoratorStream{
    
    Stream* stream;//...
    
public:
    BufferedStream(Stream* stm):DecoratorStream(stm){
        
    }
    //...
};

void Process(){
    //运行时装配
    FileStream* s1=new FileStream();
    
    CryptoStream* s2=new CryptoStream(s1);
    
    BufferedStream* s3=new BufferedStream(s1);
    
    BufferedStream* s4=new BufferedStream(s2);
    
}

7.3 模式定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。

7.4 结构

在这里插入图片描述

7.5 要点总结

通过采用组合而非继承的首发，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实际上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类（继承是为了确定接口的定义规范，也是体现Is_A的思想，组合是为了能够多态的使用父类的一些子类）。
Decorator 模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

8. Bridge 桥模式

8.1 动机

由于某些类型的固有的实现逻辑，使得他们具有两个变化的维度，乃至多个维度的变化。
如何应对这种“多个维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？

8.2 代码

class Messager {
protected:
	MessagerImp* messagerImp;//...
public:
	virtual void Login(string username, string password) = 0;
	virtual void SendMessage(string message) = 0;
	virtual void SendPicture(Image image) = 0;

	virtual ~Messager() {}
};

class MessagerImp {                // 针对不同的平台有不同的实现方式
public:
	virtual void PlaySound() = 0;
	virtual void DrawShape() = 0;
	virtual void WriteText() = 0;
	virtual void Connect() = 0;

	virtual MessagerImp() {}
};


//平台实现 n
class PCMessagerImp : public MessagerImp {
public:

	virtual void PlaySound() {
		//**********
	}
	virtual void DrawShape() {
		//**********
	}
	virtual void WriteText() {
		//**********
	}
	virtual void Connect() {
		//**********
	}
};

class MobileMessagerImp : public MessagerImp {
public:

	virtual void PlaySound() {
		//==========
	}
	virtual void DrawShape() {
		//==========
	}
	virtual void WriteText() {
		//==========
	}
	virtual void Connect() {
		//==========
	}
};

//业务抽象 m
//类的数目：1+n+m
class MessagerLite :public Messager {
public:

	virtual void Login(string username, string password) {

		messagerImp->Connect();
		//........
	}
	virtual void SendMessage(string message) {

		messagerImp->WriteText();
		//........
	}
	virtual void SendPicture(Image image) {

		messagerImp->DrawShape();
		//........
	}
};

class MessagerPerfect :public Messager {
public:

	virtual void Login(string username, string password) {

		messagerImp->PlaySound();
		//********
		messagerImp->Connect();
		//........
	}
	virtual void SendMessage(string message) {

		messagerImp->PlaySound();
		//********
		messagerImp->WriteText();
		//........
	}
	virtual void SendPicture(Image image) {

		messagerImp->PlaySound();
		//********
		messagerImp->DrawShape();
		//........
	}
};

void Process() {
	//运行时装配
	MessagerImp* mPcImp = new PCMessagerImp();
	Messager* m = new Messager(mPcImp);
}

在一个类中间放置了不同的虚函数，但是这些虚函数有着不同的变化方向，因此他们本身就不适合放在同一个类中

8.3 模式定义

将抽象部分（业务功能）与实现部分（平台实现）分离，使它们都可以独立地变化。

8.4 结构

在这里插入图片描述

注意桥模式和装饰模式的区别：装饰模式，每一个子类都能独立运行，装饰类通过new一个普通子类也能进行运行。而桥模式必须两个类搭配起来使用完成功能。

8.5 要点总结

Bridge模式使用==“对象间的组合关系”==解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自的维度的变化，即“子类化”它们。
Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
Bridge模式的应用一般在==“两个非常强的变化维度”==，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

9. 对象创建模式

通过“对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
典型模式
- Factory Method
- Abstract Factory
- Prototype
- Builder

9.1 工厂方法模式

9.1.1 动机（Motivation）

在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。
如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？
通过设计模式可以把变化聚拢，而不是把变化消灭，更加方便代码的扩展，以及框架的搭建！

9.1.2 模式定义

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。

9.1.3 结构

在这里插入图片描述

9.1.4 要点总结

Factory Method 模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。
Factory Method 模式通过面向对象的方法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略。缺点在于要求创建方法/参数相同。

9.2 Abstract Factory 抽象工厂

9.2.1 动机（Motivation）

在软件系统中，经常面临着==“一系列相互依赖的对象”的创建工作==；同时，由于需求的变化，往往存在更多系列对象的创建工作。
如何应对这种变化？如何绕过常规的对象创建方法（new），提供一种“封装机制”来避免客户程序的这种“多系列具体对象创建工作”的紧耦合？

9.2.2 模式定义

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

9.2.3 结构

在这里插入图片描述
AbstractFactory和AbstractProduct 稳定
ConcreteFactory和Client 变化

9.2.4 要点总结

如果没有对应“多系列对象构建”的需求变化，则没有必要使用Abstract Factory 模式，这时候使用简单的工厂完全可以。
“系列对象”指的是在某一特定系列下的对象之间相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
Abstract Factory 模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

9.3 Prototype 原型模式

9.3.1 动机 (Motivation)

在软件系统中，经常面临着==“某些结构复杂的对象”的创建工作==；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。
如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？

9.3.2 模式定义

使用原型实例制定创建对象的种类，然后通过拷贝这些原型来创建新的对象。

9.3.4 结构

在这里插入图片描述
Prototype 稳定
ConcretePrototype 变化

9.3.5 要点总结

Prototype 模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。
Prototype 模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone。
Prototype 模式中的Clone 方法可以利用某些框架中的序列化来实现深拷贝。
如果使用工厂方法创建对象很复杂，不是简单的几步就能完成，而且又希望保留那个中间状态，则使用原型！在实际应用当中，原型使用并不是很多。

嘻嘻西西兮兮

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
C++设计模式

目录1. 设计模式简介2. 面向对象的设计原则2.1 重新认识面向对象2.2 面向对象设计原则2.2.1 依赖倒置原则（DIP）2.2.2 开放封闭原则（OCP）2.2.3 单一职责原则（SRP）2.2.4 Liskov替换原则（LSP）2.2.5 接口隔离原则（ISP）2.2.6 优先使用对象组合，而不是类继承2.2.7 封装变化点2.2.8 针对接口编程，而不是针对实现变成2.3 面向接口设计2.4 将设计原则提升为设计经验3. 模式方法 Template Method3.1 GOF-23 模式分类3.
复制链接

扫一扫