C++的7种设计模式原则

已于 2024-08-25 13:07:34 修改
阅读量862 收藏 28
点赞数 23
文章标签： c++ 设计模式
于 2024-08-10 18:29:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_55610255/article/details/141091049
版权

一、设计模式前言

设计模式（Design Patterns）的“模式”指的是一种在软件设计中经过验证的、解决特定问题的方案。它们不是具体的代码，而是解决常见设计问题的抽象方案或模板。设计模式提供了一种标准的方式来组织代码，以提高代码的重用性、可维护性和可扩展性。

设计模式通常包括以下几个方面：

  1. 问题（Problem）：描述在特定上下文中需要解决的设计问题。
  2. 解决方案（Solution）：提供一种或多种解决该问题的方法。
  3. 效果（Consequences）：说明采用该模式后可能会带来的优点和缺点。

《Design Patterns: Elements of Reusable Object-Oriented Software》，通常被称为《Gang of Four》（GoF）一书，是设计模式领域的经典之作。这本书将设计模式分为三大类：

  • 创建型模式：如单例模式、工厂模式、建造者模式等，主要解决对象创建问题。
  • 结构型模式：如适配器模式、装饰器模式、桥接模式等，主要解决类或对象的组合问题。
  • 行为型模式：如观察者模式、策略模式、状态模式等，主要解决对象间的通信和职责分配问题。

每种设计模式都有其特定的应用场景，通过使用这些模式，开发者能够更有效地管理复杂的系统设计

 二、设计模式基本原则

设计模式的最高目标应当是：高内聚、低耦合

高内聚（High Cohesion）

定义：高内聚指的是一个模块或类的职责应该高度集中，即模块或类应当完成单一且明确的功能。

特点：

  • 职责单一：一个模块或类应该只关注于完成某一个具体的功能或职责，避免过多的职责分散在一个模块中。
  • 功能相关：模块内部的功能和数据是紧密相关的，这样可以使得模块更加专注和稳定。

好处：

  • 易于理解和维护：一个模块应当只负责自己的职责

低耦合（Low Coupling）

定义：低耦合指的是一个模块或类与其他模块或类之间的依赖关系应该尽可能少，互相之间的影响最小化。

特点：

  • 独立性强：一个模块的实现和变化不应该影响到其他模块，模块之间的交互通过清晰的接口进行。
  • 接口明确：模块之间的通信应该通过接口或抽象类来实现，具体实现细节对外部隐藏。

好处：

  • 灵活性高：低耦合使得各个模块可以独立开发、测试和维护，增强了系统的灵活性。
  • 易于扩展：当需要增加新的功能或替换某个模块时，可以不影响其他模块，降低了改动的风险。
  • 增强可复用性：低耦合的模块更容易在不同的上下文中复用，因为它们不依赖于特定的实现或其他模块的内部结构

        在软件设计中，实现“高内聚、低耦合”的目标，可以使系统更加健壮、易于维护和扩展。高内聚确保了每个模块专注于自己的职责，而低耦合则减少了模块之间的依赖，增强了系统的灵活性和可维护性。这两个原则（目标）通常被视为良好软件设计的基石。

三、设计模式的7种基本原则

1）开放封闭原则OCP（Open for Extension,Closed for Modification Principle）

模块/类的变化是通过增加功能代码实现的，非修改源代码。即“软件实体（如类、模块、函数等）应该对扩展开放，对修改封闭。”

实现OCP常用方法：

  1. 使用抽象和接口：通过抽象类或接口定义模块的核心功能，然后使用具体的实现类来扩展功能。这样，你可以在不修改原有代码的情况下，添加新的实现类来扩展功能。

  2. 使用设计模式：

    • 策略模式（Strategy Pattern）：可以通过定义策略接口和不同的策略实现来实现功能的扩展，而不修改现有的代码。
    • 装饰器模式（Decorator Pattern）：允许你通过包装现有的对象来添加新的功能，而不改变原有对象的代码。
    • 模板方法模式（Template Method Pattern）：通过定义一个算法的骨架，并允许子类重写某些步骤，从而实现功能的扩展。

设计模式后面会详细讲述，这里使用代码简单演示下OCP的方法。

// 模拟银行业务代码功能实现的迭代，符合开放封闭原则

  • 对扩展开放：代码允许通过增加新的派生类（如autoTransferAccountsWorker 、autoPayWorker和autoDepositWorker ）来扩展业务功能，而不需要修改现有的BankWorker类及其子类。这符合开放封闭原则中“对扩展开放”的要求。

  • 对修改封闭：代码的设计避免了对现有类（如BankWorker和已有的业务类）进行修改。只需创建新的业务类并实现 doWorking() 方法即可扩展功能。这也符合开放封闭原则中“对修改封闭”的要求。

ocp.cpp

#include <iostream>
using namespace std;

class BankWork
{
public:
	void deposit()
	{
		std::cout << "存款: " << std::endl;
	}

	void transferAccounts()
	{
		std::cout << "转账: " << std::endl;
	}

	void pay()
	{
		std::cout << "缴费: " << std::endl;
	}
protected:
private:
};

class BankWorker : public BankWork
{
public:
	virtual void doWorking() = 0;
};

//已存在的业务
class  DepositWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "存款: " << std::endl;
	}
};

class  transferAccountsWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "转账: " << std::endl;
	}
};

class  PayWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "缴费: " << std::endl;
	}
};

//扩展业务
class  autoTransferAccountsWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "批量转账: " << std::endl;
	}
};

class  autoPayWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "批量缴费: " << std::endl;
	}
};

//又一个新扩展的业务
class  autoDepositWorker : public BankWorker
{
public:
	virtual void doWorking()
	{
		std::cout << "批量存款: " << std::endl;
	}
};


//传统的业务调用
void main001()
{
	BankWork *ptr = new BankWork ;
	ptr->deposit();
	ptr->transferAccounts();
	ptr->pay();
	delete ptr;
	std::cout << "传统的业务调用完成! " << std::endl;
	return ;
}

//新的业务调用
void main002()
{
	BankWorker *new_ptr  = NULL;
	new_ptr = new DepositWorker;
	new_ptr->doWorking(); //有多态发生
	delete new_ptr;

	new_ptr = new transferAccountsWorker;
	new_ptr->doWorking(); //有多态发生
	delete new_ptr;
	
	new_ptr = new PayWorker;
	new_ptr->doWorking(); //有多态发生
	delete new_ptr;
	std::cout << "新的业务调用完成! " << std::endl;
	return ;
}

//框架函数
void howDo(BankWorker *ptr)
{
	ptr->doWorking(); //有多态发生
}

//扩展业务调用
void main003()
{

	BankWorker *new_ptr  = NULL;
	new_ptr = new autoTransferAccountsWorker;
	howDo(new_ptr);
	delete new_ptr;

	new_ptr = new autoPayWorker;
	howDo(new_ptr);
	delete new_ptr;

	new_ptr = new autoDepositWorker;
	howDo(new_ptr);
	delete new_ptr;
	std::cout << "扩展业务调用完成! " << std::endl;
	return ;
}
int main()
{
//调用业务
	main001();
	main002();
	main003();
}

运行效果

 

2）依赖倒置原则DIP（Dependence Inversion Principle）

依赖于抽象的接口，不依赖具体的实现（类/模块），即依赖于接口编程，其核心思想是：高层模块不应该依赖于低层模块。两者都应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。

实现DIP常用方法：

  1. 使用接口或抽象类：将高层模块和低层模块的依赖关系抽象化。例如，定义一个接口或抽象类，低层模块实现这个接口，而高层模块依赖于这个接口。

  2. 依赖注入（Dependency Injection）：通过构造函数注入、方法注入或属性注入等方式，将依赖项传递给需要它们的类，从而使高层模块和低层模块之间的依赖关系变得松散。

DIP的示例：

  1. Bankworker类依赖于 DepositInterface、TransferAccountsInterface 和 PayInterface 接口，而不是具体的实现类。这样，BankWorker可以使用任何实现了这些接口的类。

  2. 具体实现类仍然是 DepositWorker、TransferAccountsWorker 和 PayWorker。这些实现类可以独立开发和测试，不需要修改BankWorker。

  3. 依赖注入则通过构造函数将具体的实现类传递给 BankWorker。这样，BankWorker 不再直接创建具体的实现对象，而是通过接口来使用它们。

  4. howDo 函数用于处理扩展业务，它仍然依赖于接口，这样可以处理不同的具体实现而不需要修改其代码。

dip.cpp

#include <iostream>
#include <memory>

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 高层模块：业务处理器
class BankWorker
{
public:
    BankWorker(std::unique_ptr<DepositInterface> depositImpl,
               std::unique_ptr<TransferAccountsInterface> transferImpl,
               std::unique_ptr<PayInterface> payImpl)
        : depositImpl(std::move(depositImpl)),
          transferImpl(std::move(transferImpl)),
          payImpl(std::move(payImpl)) {}

    void deposit() const
    {
        depositImpl->deposit();
    }

    void transferAccounts() const
    {
        transferImpl->transferAccounts();
    }

    void pay() const
    {
        payImpl->pay();
    }

private:
    std::unique_ptr<DepositInterface> depositImpl;
    std::unique_ptr<TransferAccountsInterface> transferImpl;
    std::unique_ptr<PayInterface> payImpl;
};

// 具体实现类
class DepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }
};

class TransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }
};

class PayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 扩展业务处理器
class AutoTransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "批量转账: " << std::endl;
    }
};

class AutoPayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "批量缴费: " << std::endl;
    }
};

class AutoDepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "批量存款: " << std::endl;
    }
};

// 框架函数
template<typename T>
void howDo(const std::unique_ptr<T>& ptr)
{
    if constexpr (std::is_base_of<DepositInterface, T>::value) {
        ptr->deposit();
    }
    if constexpr (std::is_base_of<TransferAccountsInterface, T>::value) {
        ptr->transferAccounts();
    }
    if constexpr (std::is_base_of<PayInterface, T>::value) {
        ptr->pay();
    }
}

// 传统的业务调用
void main001()
{
    BankWorker worker(
        std::make_unique<DepositWorker>(),
        std::make_unique<TransferAccountsWorker>(),
        std::make_unique<PayWorker>());

    worker.deposit();
    worker.transferAccounts();
    worker.pay();
    std::cout << "传统的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main002()
{
    std::unique_ptr<AutoTransferAccountsWorker> autoTransferWorker = std::make_unique<AutoTransferAccountsWorker>();
    howDo(autoTransferWorker);

    std::unique_ptr<AutoPayWorker> autoPayWorker = std::make_unique<AutoPayWorker>();
    howDo(autoPayWorker);

    std::unique_ptr<AutoDepositWorker> autoDepositWorker = std::make_unique<AutoDepositWorker>();
    howDo(autoDepositWorker);

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    return 0;
}

运行效果

 

3）迪米特法则LoD（Law of Demeter）

迪米特法则又被称为"最少知识原则"，"不要和陌生人说话原则"，一个对象/模块应当对其他对象/模块尽可能的不了解，以降低各个对象/模块之间的耦合关系，整体提高系统的可维护性、健壮性。

LoD的核心要点：

  1. 每个对象应当只与其直接的朋友对象通信。换句话说，方法只能调用：

    • 对象的自身的方法。
    • 作为参数传递进来的对象的方法。
    • 对象创建的（例如，通过构造函数或工厂方法）对象的方法。
    • 对象的成员变量（成员变量应当是该类的内部实现的一部分）。

  2. 避免链式调用。即对象 A 不应直接调用对象 B 的方法，然后再通过对象 B 调用对象 C 的方法。这样会使得对象 A 对对象 C 的实现细节产生依赖，从而增加耦合度。

实现LoD常用方法：

  1. 封装数据：将数据和操作数据的方法封装在一个类中，尽量减少外部对这些数据的直接访问。

  2. 使用接口：通过接口定义模块之间的交互，而不是直接操作对象的内部状态。

  3. 控制方法访问范围：尽量将方法和数据的访问范围控制在最小的范围内。例如，使用私有（private）或保护（protected）访问修饰符来限制访问

LoD的示例：

1、设置函数howDo(const T& obj)为操作对象的引用（或指针），避免直接对具体实现类的操作，

2、设置BankWorker 设计为只与接口 DepositInterface、TransferAccountsInterface 和 PayInterface 交互，而不是具体的实现类。

lod.cpp

#include <iostream>
#include <memory>

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 高层模块：业务处理器
class BankWorker
{
public:
    BankWorker(std::unique_ptr<DepositInterface> depositImpl,
               std::unique_ptr<TransferAccountsInterface> transferImpl,
               std::unique_ptr<PayInterface> payImpl)
        : depositImpl(std::move(depositImpl)),
          transferImpl(std::move(transferImpl)),
          payImpl(std::move(payImpl)) {}

    void deposit() const
    {
        depositImpl->deposit();
    }

    void transferAccounts() const
    {
        transferImpl->transferAccounts();
    }

    void pay() const
    {
        payImpl->pay();
    }

private:
    std::unique_ptr<DepositInterface> depositImpl;
    std::unique_ptr<TransferAccountsInterface> transferImpl;
    std::unique_ptr<PayInterface> payImpl;
};

// 具体实现类
class DepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }
};

class TransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }
};

class PayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 扩展业务处理器
class AutoTransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "批量转账: " << std::endl;
    }
};

class AutoPayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "批量缴费: " << std::endl;
    }
};

class AutoDepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "批量存款: " << std::endl;
    }
};

// 框架函数
template<typename T>
void howDo(const T& obj)
{
    if constexpr (std::is_base_of<DepositInterface, T>::value) {
        obj.deposit();
    }
    if constexpr (std::is_base_of<TransferAccountsInterface, T>::value) {
        obj.transferAccounts();
    }
    if constexpr (std::is_base_of<PayInterface, T>::value) {
        obj.pay();
    }
}

// 传统的业务调用
void main001()
{
    BankWorker worker(
        std::make_unique<DepositWorker>(),
        std::make_unique<TransferAccountsWorker>(),
        std::make_unique<PayWorker>());

    worker.deposit();
    worker.transferAccounts();
    worker.pay();
    std::cout << "传统的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main002()
{
    std::unique_ptr<AutoTransferAccountsWorker> autoTransferWorker = std::make_unique<AutoTransferAccountsWorker>();
    howDo(*autoTransferWorker);

    std::unique_ptr<AutoPayWorker> autoPayWorker = std::make_unique<AutoPayWorker>();
    howDo(*autoPayWorker);

    std::unique_ptr<AutoDepositWorker> autoDepositWorker = std::make_unique<AutoDepositWorker>();
    howDo(*autoDepositWorker);

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    return 0;
}

 运行效果

4）单一职责原则SRP（Single Responsibility Principle）

类/模块职责（功能）要单一，即对外尽可能的只提供一种功能，也希望引起功能变化的原因只有一个。SRP的核心思想是：一个类应该只有一个原因引起它的变化。

SRP的好处：

  1. 提高代码的可维护性：如果一个类只承担一个职责，当这个职责发生变化时，只需要修改这个类，减少了对其他部分的影响。
  2. 增强代码的可读性：单一职责的类通常更小、更专注，易于理解和阅读。
  3. 提高代码的可重用性：职责单一的类可以在其他项目中更容易地复用，因为它的功能和行为更明确。
  4. 简化测试：职责明确的类更容易进行单元测试，因为它们的行为更集中和专一

SRP的示例：

  1. 分离处理类：BankWorker 被拆分为 DepositProcessor、TransferProcessor 和 PayProcessor。每个处理器类负责一种业务操作的处理。

  2. 具体业务类：具体的实现类（如 DepositWorker 和 AutoDepositWorker）直接传递给处理器类。

srp.cpp

#include <iostream>
#include <memory>

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 具体实现类
class DepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }
};

class TransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }
};

class PayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 扩展业务实现类
class AutoDepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "批量存款: " << std::endl;
    }
};

class AutoTransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "批量转账: " << std::endl;
    }
};

class AutoPayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "批量缴费: " << std::endl;
    }
};

// 业务处理器
class DepositProcessor
{
public:
    DepositProcessor(std::unique_ptr<DepositInterface> depositImpl)
        : depositImpl(std::move(depositImpl)) {}

    void process() const
    {
        depositImpl->deposit();
    }

private:
    std::unique_ptr<DepositInterface> depositImpl;
};

class TransferProcessor
{
public:
    TransferProcessor(std::unique_ptr<TransferAccountsInterface> transferImpl)
        : transferImpl(std::move(transferImpl)) {}

    void process() const
    {
        transferImpl->transferAccounts();
    }

private:
    std::unique_ptr<TransferAccountsInterface> transferImpl;
};

class PayProcessor
{
public:
    PayProcessor(std::unique_ptr<PayInterface> payImpl)
        : payImpl(std::move(payImpl)) {}

    void process() const
    {
        payImpl->pay();
    }

private:
    std::unique_ptr<PayInterface> payImpl;
};

// 传统的业务调用
void main001()
{
    DepositProcessor depositProcessor(std::make_unique<DepositWorker>());
    TransferProcessor transferProcessor(std::make_unique<TransferAccountsWorker>());
    PayProcessor payProcessor(std::make_unique<PayWorker>());

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();
    std::cout << "传统的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main002()
{
    DepositProcessor depositProcessor(std::make_unique<AutoDepositWorker>());
    TransferProcessor transferProcessor(std::make_unique<AutoTransferAccountsWorker>());
    PayProcessor payProcessor(std::make_unique<AutoPayWorker>());

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    return 0;
}

运行效果

 

5）接口隔离原则ISP（Interface Segregation Principle）

一个类不应被迫依赖它不使用的方法。换句话说，一个接口应当尽可能地保持简单和专注，避免将过多的职责集中在一个接口上。

ISP的核心思想是：客户端不应该依赖于它不需要的接口。

ISP的好处：

  1. 减少耦合：当接口被拆分成多个小接口时，每个客户端只依赖于它所需要的部分，减少了不必要的依赖。
  2. 提高灵活性：系统中的类只实现它们需要的接口，易于进行修改和扩展。
  3. 增强可维护性：小的接口通常更简单，易于理解和维护。
  4. 提升可重用性：小接口具有明确的责任，可以在不同的上下文中重用。

接口隔离原则的主要目标是避免“胖接口”（fat interface），即一个接口包含过多的方法。

实现ISP的常用方法：

  1. 分析接口的职责：识别接口中的不同职责，将它们拆分成多个小的接口。
  2. 定义专注的接口：创建专注于单一功能的小接口，以减少不必要的依赖。
  3. 采用组合：通过接口的组合来实现复杂的功能，而不是将所有功能放在一个接口中。
  4. 避免接口膨胀：避免将过多的方法放在一个接口中，保持接口的简单性和专注性。

ISP的示例：

  1. 接口设计：将BankWorker类拆分为多个接口（DepositInterface、TransferAccountsInterface、PayInterface），这样每个接口只包含一个特定的业务功能。符合接口隔离原则，提高了代码的灵活性和可维护性。

isp.cpp

#include <iostream>
#include <memory>

// 基类
class BankWork
{
public:
    virtual ~BankWork() = default;

    virtual void deposit() const
    {
        std::cout << "存款: " << std::endl;
    }

    virtual void transferAccounts() const
    {
        std::cout << "转账: " << std::endl;
    }

    virtual void pay() const
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 业务处理类
class BankWorker : public DepositInterface, public TransferAccountsInterface, public PayInterface
{
public:
    virtual ~BankWorker() = default;

    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }

    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }

    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 业务处理器
class DepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }
};

class TransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }
};

class PayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 扩展业务
class AutoTransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "批量转账: " << std::endl;
    }
};

class AutoPayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "批量缴费: " << std::endl;
    }
};

class AutoDepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "批量存款: " << std::endl;
    }
};

// 框架函数
template<typename T>
void howDo(const std::unique_ptr<T>& ptr)
{
    // 先检查 T 是否实现了相关接口
    if constexpr (std::is_base_of<DepositInterface, T>::value) {
        ptr->deposit();
    }
    if constexpr (std::is_base_of<TransferAccountsInterface, T>::value) {
        ptr->transferAccounts();
    }
    if constexpr (std::is_base_of<PayInterface, T>::value) {
        ptr->pay();
    }
}

// 传统的业务调用
void main001()
{
    std::unique_ptr<BankWorker> ptr = std::make_unique<BankWorker>();
    ptr->deposit();
    ptr->transferAccounts();
    ptr->pay();
    std::cout << "传统的业务调用完成! " << std::endl;
}

// 新的业务调用
void main002()
{
    std::unique_ptr<DepositWorker> depositWorker = std::make_unique<DepositWorker>();
    depositWorker->deposit();

    std::unique_ptr<TransferAccountsWorker> transferWorker = std::make_unique<TransferAccountsWorker>();
    transferWorker->transferAccounts();

    std::unique_ptr<PayWorker> payWorker = std::make_unique<PayWorker>();
    payWorker->pay();

    std::cout << "新的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main003()
{
    std::unique_ptr<AutoTransferAccountsWorker> autoTransferWorker = std::make_unique<AutoTransferAccountsWorker>();
    howDo(autoTransferWorker);

    std::unique_ptr<AutoPayWorker> autoPayWorker = std::make_unique<AutoPayWorker>();
    howDo(autoPayWorker);

    std::unique_ptr<AutoDepositWorker> autoDepositWorker = std::make_unique<AutoDepositWorker>();
    howDo(autoDepositWorker);

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    main003();
    return 0;
}

运行效果

 

6）里氏替换原则LSP（Liskov Substitution Principle）

如果 S 是 T 的子类型，那么在程序中的对象类型 T 替换为 S 时，程序的行为不应发生变化。换句话说，子类对象应当能够替换掉父类对象，而不改变程序的正确性。其核心思想是：子类对象必须能够替换父类对象而不影响程序的正确性。

LSP的好处：

  1. 增强可替换性：子类可以替代父类，增加了系统的灵活性和可扩展性。
  2. 提高可维护性：符合 LSP 的系统设计更容易进行维护和扩展，因为子类与基类之间的关系更明确。
  3. 减少错误：遵循 LSP 可以避免在使用子类时出现意外的错误或不一致的行为。
  4. 增强可靠性：系统的行为在替换子类时保持一致，提高了系统的可靠性。

实现LSP的常用方法：

  1. 确保子类的行为符合父类的契约：子类应当遵循父类的接口，不改变父类方法的预期行为。
  2. 避免在子类中抛出异常：子类的方法不应抛出父类方法未预料的异常。
  3. 维护一致性：子类应当在行为和状态上与父类一致，不应引入新的约束或改变已有的约束。
  4. 使用抽象类或接口：当有多个子类有不同的行为时，可以使用抽象类或接口来定义通用的功能，避免将所有功能放在一个类中。

LSP的示例：

创建了一个模板类 Processor，它可以用于处理任何实现了 DepositInterface、TransferAccountsInterface 或 PayInterface 的对象。为了使代码保持一致性，为每个接口类型专门化了 Processor 类。这样可以确保 Processor 只依赖于基接口，并且所有实现类都可以按需替换而不会改变程序的行为。

lsp.cpp

#include <iostream>
#include <memory>

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 具体实现类
class DepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "存款: " << std::endl;
    }
};

class TransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "转账: " << std::endl;
    }
};

class PayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "缴费: " << std::endl;
    }
};

// 扩展业务实现类
class AutoDepositWorker : public DepositInterface
{
public:
    void deposit() const override
    {
        std::cout << "批量存款: " << std::endl;
    }
};

class AutoTransferAccountsWorker : public TransferAccountsInterface
{
public:
    void transferAccounts() const override
    {
        std::cout << "批量转账: " << std::endl;
    }
};

class AutoPayWorker : public PayInterface
{
public:
    void pay() const override
    {
        std::cout << "批量缴费: " << std::endl;
    }
};

// 业务处理器
template <typename T>
class Processor
{
public:
    Processor(std::unique_ptr<T> impl) : impl(std::move(impl)) {}

    void process() const
    {
        impl->execute();
    }

private:
    std::unique_ptr<T> impl;
};

// 处理器特化
template <>
class Processor<DepositInterface>
{
public:
    Processor(std::unique_ptr<DepositInterface> depositImpl)
        : depositImpl(std::move(depositImpl)) {}

    void process() const
    {
        depositImpl->deposit();
    }

private:
    std::unique_ptr<DepositInterface> depositImpl;
};

template <>
class Processor<TransferAccountsInterface>
{
public:
    Processor(std::unique_ptr<TransferAccountsInterface> transferImpl)
        : transferImpl(std::move(transferImpl)) {}

    void process() const
    {
        transferImpl->transferAccounts();
    }

private:
    std::unique_ptr<TransferAccountsInterface> transferImpl;
};

template <>
class Processor<PayInterface>
{
public:
    Processor(std::unique_ptr<PayInterface> payImpl)
        : payImpl(std::move(payImpl)) {}

    void process() const
    {
        payImpl->pay();
    }

private:
    std::unique_ptr<PayInterface> payImpl;
};

// 传统的业务调用
void main001()
{
    Processor<DepositInterface> depositProcessor(std::make_unique<DepositWorker>());
    Processor<TransferAccountsInterface> transferProcessor(std::make_unique<TransferAccountsWorker>());
    Processor<PayInterface> payProcessor(std::make_unique<PayWorker>());

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();
    std::cout << "传统的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main002()
{
    Processor<DepositInterface> depositProcessor(std::make_unique<AutoDepositWorker>());
    Processor<TransferAccountsInterface> transferProcessor(std::make_unique<AutoTransferAccountsWorker>());
    Processor<PayInterface> payProcessor(std::make_unique<AutoPayWorker>());

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    return 0;
}

运行效果

 

7）优先使用组合，而非继承原则（Favor Composition over Inheritance）

在设计类的结构时，应该优先考虑使用对象组合的方式来实现功能，而不是通过继承来扩展类的功能。

组合（Composition） 指的是通过将一个类的实例作为另一个类的成员变量来实现功能的复用。例如，通过组合将一个对象的功能嵌入到另一个对象中，从而实现扩展和复用。

继承（Inheritance） 是通过创建一个新类（子类）来扩展或修改已有类（父类）的功能。子类继承父类的所有公共属性和方法，并可以覆盖或扩展它们。

使用组合的好处： 

  1. 减少耦合：组合使得类之间的关系更加松散，减少了对父类实现细节的依赖，从而降低了类之间的耦合度。
  2. 增强灵活性：通过组合可以灵活地改变对象的行为或功能，而不需要修改现有的类。它使得系统可以在运行时动态地改变对象的行为。
  3. 提高可维护性：组合比继承更容易进行修改和维护，因为更改一个组件的实现通常不会影响到其他组件。
  4. 避免“继承深度”问题：继承可能导致深层次的继承链，使得系统复杂度增加，而组合可以避免这种情况。

 判断是否适合组合的常用方法：

  1. 识别可复用的功能：分析系统中需要复用的功能，确定是否可以通过组合来实现这些功能，而不是通过继承。
  2. 使用接口和抽象类：通过接口或抽象类定义功能的契约，然后通过组合将具体的实现注入到类中。
  3. 设计模块化的组件：将功能划分为独立的组件，这些组件可以被组合在一起以实现复杂的功能。
  4. 避免过度使用继承：继承应该仅用于表示“是一个”（is-a）关系，而不是“有一个”（has-a）关系。对于“有一个”关系，组合通常是更合适的选择。

组合的示例：

  • 函数对象：在Processor中使用std::function来传递具体的业务逻辑。这使得Processor不再依赖具体的实现类。
  • 业务逻辑：在main001和main002中，直接定义了业务逻辑的函数对象，这样可以根据需要在代码中灵活地调整行为，而不需要创建新的类。

composition.cpp

#include <iostream>
#include <memory>
#include <functional>

// 业务接口
class DepositInterface
{
public:
    virtual ~DepositInterface() = default;
    virtual void deposit() const = 0;
};

class TransferAccountsInterface
{
public:
    virtual ~TransferAccountsInterface() = default;
    virtual void transferAccounts() const = 0;
};

class PayInterface
{
public:
    virtual ~PayInterface() = default;
    virtual void pay() const = 0;
};

// 业务处理器
template <typename T>
class Processor
{
public:
    Processor(std::function<void()> func) : func(func) {}

    void process() const
    {
        func();
    }

private:
    std::function<void()> func;
};

// 传统的业务调用
void main001()
{
    Processor<DepositInterface> depositProcessor([]() {
        std::cout << "存款: " << std::endl;
    });

    Processor<TransferAccountsInterface> transferProcessor([]() {
        std::cout << "转账: " << std::endl;
    });

    Processor<PayInterface> payProcessor([]() {
        std::cout << "缴费: " << std::endl;
    });

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();

    std::cout << "传统的业务调用完成! " << std::endl;
}

// 扩展业务调用
void main002()
{
    Processor<DepositInterface> depositProcessor([]() {
        std::cout << "批量存款: " << std::endl;
    });

    Processor<TransferAccountsInterface> transferProcessor([]() {
        std::cout << "批量转账: " << std::endl;
    });

    Processor<PayInterface> payProcessor([]() {
        std::cout << "批量缴费: " << std::endl;
    });

    depositProcessor.process();
    transferProcessor.process();
    payProcessor.process();

    std::cout << "扩展业务调用完成! " << std::endl;
}

int main()
{
    main001();
    main002();
    return 0;
}

运行效果

 

四、设计模式经典之作

ps:《Design Patterns: Elements of Reusable Object-Oriented Software》一书是一本经典设计模式的作品，推荐去看看。"Gang of Four"书名来源于书籍的四位作者，他们分别是：

  1. Erich Gamma（艾里希·伽玛）
  2. Richard Helm（理查德·赫尔姆）
  3. Ralph Johnson（拉尔夫·约翰逊）
  4. John Vlissides（约翰·弗利西德斯）

这四位作者在书中总结并分类了设计模式，这本书在软件工程领域中具有重要的影响力，因此他们被戏称为《Gang of Four》。这个名字传达了他们在设计模式领域的权威地位，并且也带有一种略显俏皮的意味。

英文本封面

凢曐
关注
C++七项设计原则与常见设计模式
kuailedegouyibacao的博客
07-13 927
C++七项设计原则和常见设计模式 一、C++面向对象设计的的七大设计原则 单一职责原则: 就是一个类只负责一个职责, 只有一个引起变化的原因。 例如：调制解调器：将连接看作一个职责，数据传送看作一个职责，两者需要分离开； 里氏替换原则：任何基类可以出现的地方,子类一定可 以出现，子类一定要能够被当成基类使用； 例如：手枪，步枪，机关枪，玩具枪等都属于枪，但如果在射击游戏场景中，就不能够使用玩具枪，因此，玩具枪应该单独成为一个类，否则就违反了里氏替换原则； 依赖倒置原则：依赖倒置原则就是要依赖于抽象,不.
c++设计模式
心愿许得无限大
03-05 1903
c++设计模式
2.设计模式-七大原则(C++)
抵抗时间扭曲，坚持做一件有意义的事
07-03 634
任何一个设计模式都离不开七大原则中的任一原则.所以七大原则非常重要,只要我们明白了七大原则,就可以知道如何在项目中使用什么设计原则了. 设计模式的七大原则如下所示: 1.单一职责原则 2.开放-封闭原则 3.依赖倒置原则 4.里氏替换原则(LSP) 5.接口隔离原则 6.迪米特原则(最少知道原则) 7.合成复用原则 1.单一职责原则 一个类应该仅有一个引起它变化的原因。 变化的方向隐含着类...
【设计模式学习笔记】设计模式七大原则介绍（基于C++实现）
仅以此博客记录日常学习工作中所思所得，水平有限，难登大雅，万望海涵。
04-14 800
设计模式的最终目的就是：提高内聚、降低耦合。
C++设计模式——八个原则
最新发布
pigbossa的博客
01-12 797
C++设计模式的八个原则
C++ 设计模式之遵循原则
m_wordPlan的博客
01-19 357
目录 设计模式之遵循原则 1. 单一职责原则(SRP) 1.1 设计目的 1.2 定义 1.3 应用 2. 开放-封闭原则(OCP) 2.1 设计目的 2.2 定义 2.3 应用 3. 依赖倒转原则 3.1 设计目的 3.2 定义 3.3 应用 4. 迪米特法则(LoD,最少知识原则) 4.1 设计目的 4.2 定义 4.3 应用 设计模式之遵循原则 注...
C++ 23种设计模式.zip
07-29
本资源"**C++ 23种设计模式.zip**"包含了C++版本的设计模式详细讲解，旨在帮助开发者提升编程技能和团队协作效率。 1. **单例模式（Singleton）**：确保一个类只有一个实例，并提供一个全局访问点。在C++中，可以...
C++ Design Pattern 23种设计模式(全_解释+源代码).zip
01-16
C++设计模式是一种在软件开发中经过验证的通用解决方案，它们是解决常见问题的经验总结，可以提高代码的可重用性、可维护性和可扩展性。在这个"C++ Design Pattern 23种设计模式(全_解释+源代码).zip"压缩包中，包含...
23种设计模式解析附C++实现
09-29
下面是23种设计模式的详细解析和它们在C++中的实现方法。 创建型模式涉及对象的创建机制，帮助创建对象的同时隐藏创建逻辑，而不是使用新的来直接实例化对象。常见的创建型模式有： 1. Factory模式，也称为简单...
23种设计模式(C++).pdf
12-05
通过学习和实践23种设计模式，我们可以更好地理解面向对象设计的原则，提高软件设计的质量。无论是初学者还是有一定经验的开发者，都能从中受益匪浅。最重要的是，在学习的过程中，我们需要不断思考、总结和实践，...
23种设计模式(C++)
01-09
23种设计模式(C++) . .
C++设计模式（一）——面对对象设计原则
ItaLink
09-27 374
面对对象设计原则 没有规矩不成方圆，现实世界何尝不是，那你可曾想过为什么要制定规则呢？每个人或事物或代码都可以有自己的规则，当我们（或其他）交流的时候，无可避免的就会有一些相互矛盾的规则，这样的冲突具有很强的破坏性，势必会导致双方规则僵持甚至被损坏。因此，为了不产生冲突，我们都会”约法三章“，指定一个“共同”的规则，只要双方都遵守这个规则，那么就不容易产生冲突。这里的双方不只是自己与他人，也可能...
C++设计模式——设计原则
qq_35718950的博客
11-05 151
c++设计模式原则
设计模式（C++实现）（一）——设计模式总原则及六大原则
huashuolin001的博客
05-11 923
设计模式六大原则 总原则：开闭原则（Open Close Principle）。开闭原则就是说对扩展开放，对修改关闭。 1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。 2、里氏替换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principl...
C++设计模式（一）四种法则
log_Li的博客
07-13 245
设计模式（一）软件设计模式的种类面向对象设计原则面向对象设计原创表开闭原则迪米特法则依赖倒转原则合成复用原则 软件设计模式的种类 GoF提出的设计模式有23个，包括： 创建型(Creational)模式： 如何创建对象； 结构型(Structural )模式： 如何实现类或对象的组合； 行为型(Behavioral)模式： 类或对象怎样交互以及怎样分配职责。 设计模式目前种类： GoF的23种 + “简单工厂模式” = 24种。 设计模式的基础是：多态。 面向对象设计原则 面向对象设计原则为支持可维护性复用
C++设计模式——八大设计原则
赵小厨的博客
10-03 1305
引言 在学习的过程中，我通常会分为三步，吸收消化、表达出来、教会他人。如果能达到通俗易懂的方式教会他人，那必定对该知识点十分熟悉。所以我也想尝试通过将设计模式给写出来、表达出来、使自己对设计模式有更加深刻的一个理解，同时也给别人参考学习。如果有不正确的地方，欢迎纠正。 概述 设计模式体现的是一种思想，理解和掌握了设计模式，并不是说记住了 23 种设计场景和解决策略（实际上这也是很重要的一笔财富），...
C++设计模式的设计原则（面向对象八大设计原则）
不负AC不负卿的博客
07-10 3912
C++设计模式八大原则的讲解，面向对象八大设计原则的讲解，以简单易懂、有趣论说来讲解八大设计原则
设计模式六大原则
每天学点c++
11-17 1070
设计模式六大原则（1）：单一职责原则 定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。  问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，
C++实现的GoF23种设计模式解析
"C++ 设计模式是面向...以上是对C++设计模式资源的详尽概述，包括GOF的23种设计模式及其在C++中的实现，以及它们在实际开发中的应用和价值。通过学习这些模式，开发者能够更好地理解和实践面向对象分析和设计的原则。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值