C++ 学习 12 设计模式 2

最新推荐文章于 2024-09-09 19:32:06 发布
最新推荐文章于 2024-09-09 19:32:06 发布
阅读量513 收藏
点赞数
分类专栏： 设计模式 文章标签： c语言 面向对象
  • 工厂方法
  • 抽象工厂
  • 原型模式
  • 构建器
  • 单例模式
  • 享元模式
  • 门面模式
  • 代理模式
  • 适配器
  • 中介者

对象创建模式

通过对象创建模式绕开new，来避免对象创建（new），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
典型模式
Factory Method
Abstract Factory
Prototype
Builder

工厂模式

动机：在软件系统中经常面临着创建对象的工作；由于需求的变化，需要创建的对象具体类型经常变化。如何应对这种变化？如何绕开常规的对象创建方法（new），提供一种封装机制来避免客户程序和这种具体对象创建工作的紧耦合？

定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。FactoryMethod 使得一个雷德实例化延迟（目的：解耦，手段：虚函数）到子类。
例 如下文件分割器需要支持多种类型文件分割

class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};

class BinarySplitter : public ISplitter{

};

class TxtSplitter: public ISplitter{

};

class PictureSplitter: public ISplitter{

};

class VideoSplitter: public ISplitter{

};
class MainForm : public Form
{
    TextBox* txtFilePath;
    TextBox* txtFileNumber;
    ProgressBar* progressBar;

public:
    void Button1_Click(){



        ISplitter * splitter=
            new BinarySplitter();//依赖具体类

        splitter->split();

    }
};

违反了依赖倒置原则，稳定不能依赖变化，高层不能依赖底层。
应用工厂模式


//抽象类
class ISplitter{
public:
    virtual void split()=0;
    virtual ~ISplitter(){}
};


//工厂基类
class SplitterFactory{
public:
    virtual ISplitter* CreateSplitter()=0;
    virtual ~SplitterFactory(){}
};
//具体类
class BinarySplitter : public ISplitter{

};

class TxtSplitter: public ISplitter{

};

class PictureSplitter: public ISplitter{

};

class VideoSplitter: public ISplitter{

};
/具体工厂
class BinarySplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new BinarySplitter();
    }
};

class TxtSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new TxtSplitter();
    }
};

class PictureSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new PictureSplitter();
    }
};

class VideoSplitterFactory: public SplitterFactory{
public:
    virtual ISplitter* CreateSplitter(){
        return new VideoSplitter();
    }
};
class MainForm : public Form
{
    SplitterFactory*  factory;//工厂

public:

    MainForm(SplitterFactory*  factory){
        this->factory=factory;
    }

    void Button1_Click(){


        ISplitter * splitter=
            factory->CreateSplitter(); //多态new

        splitter->split();

    }
};

对每一子类均有一个工厂类来实现其new这样在高层代码中就可以利用多态性来避免其依赖具体底层类。根据客户端传入的具体类类型来实现晚绑定。
总结 Factory Method 模式用于隔离类对象的使用者和其具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。
Factory Method 模式通过面向对象的手法， 将所要创建的具体对象工作延迟到子类，从而实现一种扩展的策略，较好地解决了这种紧耦合关系/ Factory Method 模式解决单个对象的需求变化。缺点在于要求穿件方法/参数相同。

抽象工厂

动机： 在软件系统中，经常面临一系列互相依赖的对象的创建工作；同时由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象创建方法new提供一种封装机制来避免客户程序和这种多系列具体对象创建工作的紧耦合？
定义：提供一个接口，让该接口负责穿件一系列的相关或者相互依赖的对象，无须制定它们具体的类。
例一个数据库操作类需要有connection,command, reader等几个相互依赖的类。

class IDBConnection{

};
class IDBCommand{

};
class IDataReader{

};
class SqlConnection: public IDBConnection{

};
class SqlCommand: public IDBCommand{

};
class SqlDataReader: public IDataReader{

};
class EmployeeDAO{

public:
    vector<EmployeeDO> GetEmployees(){
        SqlConnection* connection =
            new SqlConnection();
        connection->ConnectionString = "...";

        SqlCommand* command =
            new SqlCommand();
        command->CommandText="...";
        command->SetConnection(connection);

        SqlDataReader* reader = command->ExecuteReader();
        while (reader->Read()){

        }

    }
};

采用工厂方法：


//数据库访问有关的基类
class IDBConnection{

};
class IDBConnectionFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
};


class IDBCommand{

};
class IDBCommandFactory{
public:
    virtual IDBCommand* CreateDBCommand()=0;
};


class IDataReader{

};
class IDataReaderFactory{
public:
    virtual IDataReader* CreateDataReader()=0;
};


//支持SQL Server
class SqlConnection: public IDBConnection{

};
class SqlConnectionFactory:public IDBConnectionFactory{

};


class SqlCommand: public IDBCommand{

};
class SqlCommandFactory:public IDBCommandFactory{

};


class SqlDataReader: public IDataReader{

};
class SqlDataReaderFactory:public IDataReaderFactory{

};

//支持Oracle
class OracleConnection: public IDBConnection{

};

class OracleCommand: public IDBCommand{

};

class OracleDataReader: public IDataReader{

};



class EmployeeDAO{
    IDBConnectionFactory* dbConnectionFactory;
    IDBCommandFactory* dbCommandFactory;
    IDataReaderFactory* dataReaderFactory;


public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection =
            dbConnectionFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command =
            dbCommandFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //关联性

        IDBDataReader* reader = command->ExecuteReader(); //关联性
        while (reader->Read()){

        }

    }
};

由于connection ，command， reader具有关联系不能保证外部传入的具体实例正确性。
采用抽象工厂


//数据库访问有关的基类
class IDBConnection{

};

class IDBCommand{

};

class IDataReader{

};


class IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection()=0;
    virtual IDBCommand* CreateDBCommand()=0;
    virtual IDataReader* CreateDataReader()=0;

};


//支持SQL Server
class SqlConnection: public IDBConnection{

};
class SqlCommand: public IDBCommand{

};
class SqlDataReader: public IDataReader{

};


class SqlDBFactory:public IDBFactory{
public:
    virtual IDBConnection* CreateDBConnection();
    virtual IDBCommand* CreateDBCommand();
    virtual IDataReader* CreateDataReader();

};

//支持Oracle
class OracleConnection: public IDBConnection{

};

class OracleCommand: public IDBCommand{

};

class OracleDataReader: public IDataReader{

};



class EmployeeDAO{
    IDBFactory* dbFactory;

public:
    vector<EmployeeDO> GetEmployees(){
        IDBConnection* connection =
            dbFactory->CreateDBConnection();
        connection->ConnectionString("...");

        IDBCommand* command =
            dbFactory->CreateDBCommand();
        command->CommandText("...");
        command->SetConnection(connection); //关联性

        IDBDataReader* reader = command->ExecuteReader(); //关联性
        while (reader->Read()){

        }

    }
};

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

原型模式

动机：在软件系统中，经常面临着某些结构复杂的对象的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但他们却拥有比较稳定一致的接口。 如何应对这种变化？如何向客户程序（使用这些对象的程序）隔离出这些易变对象从而使得依赖这些易变对象的客户程序不随着需求改变而改变？
定义：使用原型实例制定创建对象的种类，然后通过拷贝这些原型来创建新对象。

//prototype
//抽象类
class ISplitter{
public:
    virtual void split()=0;
    virtual ISplitter* clone()=0; //通过克隆自己来创建对象

    virtual ~ISplitter(){}

};

//具体类
class BinarySplitter : public ISplitter{
public:
    virtual ISplitter* clone(){
        return new BinarySplitter(*this);
    }
};

class TxtSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new TxtSplitter(*this);
    }
};

class PictureSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new PictureSplitter(*this);
    }
};

class VideoSplitter: public ISplitter{
public:
    virtual ISplitter* clone(){
        return new VideoSplitter(*this);
    }
};

//Client
class MainForm : public Form
{
    ISplitter*  prototype;//原型对象

public:

    MainForm(ISplitter*  prototype){
        this->prototype=prototype;
    }

    void Button1_Click(){

        ISplitter * splitter=
            prototype->clone(); //克隆原型

        splitter->split();

    }
};

此模式需要对原对象拷贝构造函数有良好的实现。
总结 Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些易变类拥有稳定的接口。 Prototype 模式对于如何创建易变类的实例对象采用原型克隆的方法来做，它使得我们可以非常灵活地动态创建拥有某些稳定接口的新对象–所需工作仅仅是注册一个新类的对象，然后在任何需要的地方Clone。Prototype模式中的Clone 方法可以利用某些框架中的序列化来实现深拷贝。

Builder模式

动机：在软件系统中，有时候面临着一个复杂对象的创建工作，其通常是由各个部分的字对象用一定的算法构成的；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。如何应对这种变化？如何提供一种封装机制来隔离出复杂对象的各个部分的变化，从而保持系统中的稳定构建算法不随着需求改变而改变？
定义：将一个复杂对象的构建与其表示相分离，使得同样的构建过程（稳定） 可以创建不同的表示(变化)。


class House{
    //....
};

class HouseBuilder {
public:
    House* GetResult(){
        return pHouse;
    }
    virtual ~HouseBuilder(){}
protected:

    House* pHouse;
    virtual void BuildPart1()=0;
    virtual void BuildPart2()=0;
    virtual void BuildPart3()=0;
    virtual void BuildPart4()=0;
    virtual void BuildPart5()=0;

};

class StoneHouse: public House{

};

class StoneHouseBuilder: public HouseBuilder{
protected:

    virtual void BuildPart1(){
        //pHouse->Part1 = ...;
    }
    virtual void BuildPart2(){

    }
    virtual void BuildPart3(){

    }
    virtual void BuildPart4(){

    }
    virtual void BuildPart5(){

    }

};


class HouseDirector{

public:
    HouseBuilder* pHouseBuilder;

    HouseDirector(HouseBuilder* pHouseBuilder){
        this->pHouseBuilder=pHouseBuilder;
    }

    House* Construct(){

        pHouseBuilder->BuildPart1();

        for (int i = 0; i < 4; i++){
            pHouseBuilder->BuildPart2();
        }

        bool flag=pHouseBuilder->BuildPart3();

        if(flag){
            pHouseBuilder->BuildPart4();
        }

        pHouseBuilder->BuildPart5();

        return pHouseBuilder->GetResult();
    }
};

对比template method , 模板方法只是实现流程的晚绑定， 而构建器模式则是提供一个抽象类将流程隔离（houseDirector）不同的builder实现不同的流程。此处housedirector 为稳定部分。

总结：Builder模式主要用于 分布构建一个复杂的对象。而在这其中分步骤是一个稳定的算法而复杂对象的各个部分经常变化。变化点在哪里就封装那里–Builder模式主要在于应对复杂对象的各个部分的需求变动。其缺点在于难以应对分步骤构建算法的需求变动。
在builder模式中要注意不同语言中构造器内调用虚函数的差别。

接口隔离模式

在组建构建过程中某些结构之间的直接依赖常常会带来很多问题，甚至无法实现。采用添加一层间接(稳定)接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。
典型模式
Facade 门面模式，Proxy，Adapter，Mediator.

门面模式

动机：客户和组件中的各种复杂子系统有了过多的耦合随着外部刻画程序的变化哈各子系统的演化，这种过多的耦合会面临很多的挑战。 如何简化外部刻画程序和系统间的交互接口如何将外部客户程序的演化和内部子系统之间的相互依赖解耦？
定义： 为子系统中的一组接口提供一个一致（稳定）界面Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)。
这里写图片描述
总结 从客户程序角度来看Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说达到了一种解耦的效果，内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次，Facade很多时候更是一种架构设计模式。
Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是互相耦合关系比较大的一系列组件，而不是一个简单的功能集合。

Proxy代理模式

动机：在面向对象系统中，有些对象由于某些原因(比如对象创建的开销很大，或者某些操作需要安全控制，或者需要某些进程外的访问等)，直接访问会给使用者，或者系统结构带来很多麻烦。 如何在不识趣透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中的常见解决方式。
定义：为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。

class ISubject{
public:
    virtual void process();
};


class RealSubject: public ISubject{
public:
    virtual void process(){
        //....
    }
};

class ClientApp{

    ISubject* subject;

public:

    ClientApp(){
        subject=new RealSubject();
    }

    void DoTask(){
        //...
        subject->process();

        //....
    }
};

假设访问realsubject需要增加间接性，采用Proxy模式如下：

class ISubject{
public:
    virtual void process();
};


//Proxy的设计
class SubjectProxy: public ISubject{


public:
    virtual void process(){
        //对RealSubject的一种间接访问
        //....
    }
};

class ClientApp{

    ISubject* subject;

public:

    ClientApp(){
        subject=new SubjectProxy();
    }

    void DoTask(){
        //...
        subject->process();

        //....
    }
};

总结： 增加一层间接是软件系统中对许多复杂问题的一种常见解决方案。在面向对象系统中直接使用某些对象会带来很多问题，作为间接层的Proxy对象是解决这一问题的常用手段。
具体Proxy设计模式的实现方法，实现粒度都相差很大，有些可能是对象粒度的控制，如copy-on-write技术，有些可能是对组建模块提供抽象代理曾，在架构层次对对象做Proxy。
Proxy并不要求保持接口的完整一致性，只要能实现间接控制，有时候损及一些透明性是可以接受的。

Adapter 适配器模式

动机 ：在软件系统中，由于应用环境的变化，常常需要将一些现存的对象放在新的应用环境中，按时新环境要求的接口是这些现存的对象不满足的。如何应对这种迁移的变化？如何既能利用现有对象的良好实现，同时又能够满足新应用环境的接口？
定义：将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能易其工作的那些类可以一起工作。

//目标接口（新接口）
class ITarget{
public:
    virtual void process()=0;
};

//遗留接口（老接口）
class IAdaptee{
public:
    virtual void foo(int data)=0;
    virtual int bar()=0;
};

//遗留类型
class OldClass: public IAdaptee{
    //....
};

//对象适配器
class Adapter: public ITarget{ //继承
protected:
    IAdaptee* pAdaptee;//组合

public:

    Adapter(IAdaptee* pAdaptee){
        this->pAdaptee=pAdaptee;
    }

    virtual void process(){
        int data=pAdaptee->bar();
        pAdaptee->foo(data);

    }


};


//类适配器
class Adapter: public ITarget,
               protected OldClass{ //多继承


}


int main(){
    IAdaptee* pAdaptee=new OldClass();


    ITarget* pTarget=new Adapter(pAdaptee);
    pTarget->process();


}


class stack{
    deqeue container;

};

class queue{
    deqeue container;

};

适配器模式分为两种一种对象适配，另一种类适配（上述多继承）
总结：Adapter 模式主要应用于希望服用一些现存的雷，但是接口又与复用环境不兼容的情况，在一流代码复用，类库迁移等方面非常有用。
GOF23定义了两种 Adapter模式的实现结构：对象适配器和 类适配器。但类适配器采用多继承的实现方式，一般不推荐使用。对象适配器采用组合的方式更符合松耦合的精神。
Adapter模式可以实现的非常灵活，不必拘泥于GOF23中定义的两种结构。例如 STL 中 stack 和queue使用deque来实现。set/map 使用rb_tree来实现。

Mediator中介者

动机：在软件构建中，经常会出现多个对象互相关联交互的情况，对象之间经常会维持一种复杂的引用关系，如果遇到需求更改，这种直接的引用关系将面临不断的变化。在这种情况下我们可以使用一个中介对象来管理对象间的关联关系，来避免互相交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
定义：使用一个中介来封装(封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引用(编译时依赖-〉运行时依赖),从而使其耦合松散 （管理变化），而且可以独立地改变它们之间的交互。
总结：将多个对象间的复杂关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变多个对象互相管理为多个对象和一个中介者关联，简化了系统的维护，抵御了可能的变化。
岁uzhekongzhiluoj的复杂化，Mediator具体对象的实现肯呢个相当复杂，这时候可以对Mediator对象进行分解处理。
Facade是解耦系统间（单向）的对象联系；Mediator是解耦系统内各个对象之间的（双向）的关联关系。

对象性能模式

面向对象很好的解决路抽象的文题，但是必不可避免的要付出一定的代价，对于通常来讲，面向对象的成本大都可以忽略不计。但是某些情况下，面向对象所带来的成本需谨慎处理。
典型模式：
Singleton
Flyweight

Singleton单例模式

动机：在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能保证他们的逻辑正确性，以及良好的效率。
如何绕过常规构造器，提供一种机制来保证一个类只有一个实例？这应该是类设计者的责任，而不是使用者的责任。
定义：
保证一个类仅有一个实例，并提供一个该实例的全局访问点。
线程非安全版本

class Singleton{
private:
    Singleton();
    Singleton(const Singleton& other);
public:
    static Singleton* getInstance();
    static Singleton* m_instance;
};

Singleton* Singleton::m_instance=nullptr;

//线程非安全版本
Singleton* Singleton::getInstance() {
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

线程安全版

Singleton* Singleton::getInstance() {
    Lock lock;
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

错误版本

//双检查锁，但由于内存读写reorder不安全
Singleton* Singleton::getInstance() {

    if(m_instance==nullptr){
        Lock lock;
        if (m_instance == nullptr) {
            m_instance = new Singleton();
        }
    }
    return m_instance;
}

new三步骤有可能在编译期间 reorder故容易出错。
C++11 新方法


//C++ 11版本之后的跨平台实现 (volatile)
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;

Singleton* Singleton::getInstance() {
    Singleton* tmp = m_instance.load(std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load(std::memory_order_relaxed);
        if (tmp == nullptr) {
            tmp = new Singleton;
            std::atomic_thread_fence(std::memory_order_release);//释放内存fence
            m_instance.store(tmp, std::memory_order_relaxed);
        }
    }
    return tmp;
}

总结：Singleton模式中的实例构造器可以设置为protected以允许子类派生。 Singleton 模式一般不要支持拷贝构造函数和clone接口，因为这有可能导致多个实例对象，与Singleton初衷违背。

Flyweight享元模式

动机：在软件系统采用纯粹对象反感的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价–主要是指内存需求方面的代价。如何能够避免大量细粒度对象问题的同时，让外部客户程序仍能够透明地使用面向最想的方式来操作？
定义：运用共享技术有效地支持大量细粒度的对象。


class Font {
private:

    //unique object key
    string key;

    //object state
    //....

public:
    Font(const string& key){
        //...
    }
};
ß

class FontFactory{
private:
    map<string,Font* > fontPool;

public:
    Font* GetFont(const string& key){

        map<string,Font*>::iterator item=fontPool.find(key);

        if(item!=footPool.end()){
            return fontPool[key];
        }
        else{
            Font* font = new Font(key);
            fontPool[key]= font;
            return font;
        }

    }

    void clear(){
        //...
    }
};

使用map结构来构造fontpool防止font对象过多。
总结：flyweight 主要解决面向对象的代价问题，一般不触及面向对象的抽象问题。Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力，在具体实现方面要注意对象状态的处理。

BigDoole
关注
专栏目录
《C++ 设计模式》
青春不老，奋斗不止！
02-09 9万+
设计模式代表了最佳的实践，在面向对象的编程中被很多老鸟们反复使用。使用设计模式有很多好处：可重用代码、保证代码可靠性、使代码更易被他人理解 ......
C/C++学习路线总结与分享
热门推荐
dvlinker的技术专栏
10-07 8万+
C/C++学习路线总结与分享
设计模式学习笔记三：简单工厂（Simple Factory）
weixin_34148340的博客
06-06 69
    开始学习创建型模式，这些模式的使用是面向接口编程的必然结果，面向接口编程要求针对接口，而不是具体的实现，这样程序可以不用关心具体使用实现也能做到实现的互换。尽管编程是面向接口，但执行是操作需要实例化后的对象，而实例化必须要针对具体的类。如果直接实例化，则破坏了面向接口编程的原则。解决的方法就是通过一个专门实例化的类来获得具体的对象，通常我们将这个类成为“工厂”，将与实例化相关的模式成为“创...
12种设计模式C++源代码
Blog | Laulliam
12-28 2623
目录 //1.简单工厂 //2.工厂方法 //3.抽象工厂 //4.策略模式 //5.装饰模式 //6.模板方法 //7.门面模式 //8.适配器模式 //9.观察者模式 //10.建造者模式 //11.组合模式 //12.单例模式 //13. 状态模式 //14.反射机制 //1.简单工厂 class Product { public: virtu...
C++ 常见设计模式总结
qq_41952309的博客
08-22 2045
c++ 常见设计模式整理。
23种设计模式 - C++实现
阿呆的隐秘角落
08-07 5763
23种设计模式
C++设计模式 UML类图设计
qq_51969153的博客
05-18 1219
uml设计
(设计模式) (李建忠 C++) 23种设计模式
cuber-lotus的博客
12-14 4161
李建忠老师C++设计模式教程StrategyDecoratorBridgePrototypeBuilderSingletonFlyweight接口隔离:FaçadeProxyMediatorAdapter状态变化：MementoState数据结构：CompositeIterator行为变化：CommandVisitor。
《C++设计模式速览：简单入门三大类23种常用模式》
m0_72877724的博客
06-03 2128
通过学习和理解这些设计模式，你可以更有效地解决软件开发中的常见问题，并编写出更加灵活和可维护的代码。C++的灵活性和强大的面向对象编程特性使得它非常适合应用这些设计模式。敬请关注，每周更新的设计模式简单入门系列基础设计模式理解_何综瑞的博客-CSDN博客。
一文带你通俗理解23种软件设计模式（推荐收藏，适合小白学习，附带C++例程完整源码）
翟天保的博客
04-20 4万+
一文带你通俗理解23种软件设计模式（推荐收藏，适合小白学习，附带C++例程完整源码）
23种设计模式(C++).pdf
11-29
《设计模式精解－GoF 23 种设计模式解析附 C++实现源码》是一本深入探讨软件设计模式的书籍，它涵盖了创建型、结构型和行为型三种主要类型的23个经典设计模式，并提供了C++语言的实现代码。设计模式是软件工程中的...
C++设计模式学习框架
01-04
"C++设计模式学习框架"是一个专为学习和实践这些模式而构建的资源集合，它涵盖了各种常见的设计模式，帮助开发者深入理解并熟练应用到实际项目中。 设计模式通常分为三类：创建型模式（Creational Patterns）、结构...
c++设计模式-工厂方法模式
06-04
在标题“c++设计模式-工厂方法模式”中，我们关注的是如何在C++中实现工厂方法这一设计模式。工厂方法模式的核心思想是定义一个创建对象的接口，但让子类决定实例化哪一个类。这样，工厂方法可以使类的实例化过程...
C语言——在有序数组中插入一个新的元素，且数组的排列不变
qq_59990833的博客
09-09 313
数组插入元素
weixin121作品集展示微信小程序+ssm.rar
09-13
所有源码，都可正常运行
weixin090体育资讯软件的实现+ssm.rar
09-13
所有源码，都是可以运行起来的
基于java的财务管理系统设计与实现.docx
09-13
基于java的财务管理系统设计与实现.docx
吕嘉诚_训练班表.pdf
最新发布
09-13
吕嘉诚_训练班表.pdf
springboot王者荣耀游戏KPL比赛网上售票系统毕业论文.docx
09-13
springboot王者荣耀游戏KPL比赛网上售票系统毕业论文.docx
C++与Qt设计模式实战：第2版
通过学习这本书，读者不仅可以掌握C++和Qt的基础知识，还能深入了解如何在实际项目中应用设计模式，提升代码的结构和质量。此外，书中的案例和代码示例将帮助读者从开源社区的最佳实践中学习，进一步理解开放源码...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值