如何优雅地在C++库中实现实例化设计

如何优雅地在C++库中实现实例化设计

• 前言
• **工厂函数/方法**
• **建造者模式**
• 单例模式和多态
• • 单例模式
  • 多态的实现
  • 多态与单例模式的设计

前言

在设计库时，如何最好地为用户提供类的实例化方式。这通常取决于你的库设计和特定类的功能。这里有一些常见的方法：

1. 直接实例化：对于一些简单的类，用户可以直接创建实例。例如：

   MyClass obj;
   

   如果类需要构造参数，用户需要提供它们：

   MyClass obj(arg1, arg2);
   

2. 工厂函数/方法：如果类的创建过程比较复杂，或者你想隐藏某些实现细节，可以提供工厂函数或方法。工厂函数是一个返回类实例的函数，工厂方法则是返回类实例的类方法。例如：

   std::shared_ptr<MyClass> obj = MyClass::create(arg1, arg2);
   

   在这个例子中，MyClass::create是一个静态工厂方法，它返回一个MyClass的shared_ptr。
3. 单例模式：如果你的类只应该有一个实例，可以使用单例模式。在这种情况下，你通常会提供一个方法来获取类的唯一实例：

   MyClass& obj = MyClass::getInstance();
   

   这里的MyClass::getInstance是一个静态方法，它返回MyClass的引用。
4. 建造者模式：如果类有许多可选的或者需要以特定顺序设置的参数，你可以使用建造者模式。在这种情况下，你会提供一个“建造者”类，用户可以使用它来构建你的类的实例：

   MyClass obj = MyClass::Builder().setArg1(arg1).setArg2(arg2).build();
   

   这里，MyClass::Builder是一个内部类，它提供了一系列方法来设置MyClass的参数，最后调用build方法来创建MyClass的实例。

每种方法都有其适用的场景，你应该根据你的类的特性和用户的需求来选择最合适的方法。

工厂函数/方法

工厂模式是一种常见的设计模式，它提供了一个接口用于创建对象，而无需指定对象的具体类。这种模式通常用于以下场景：

1. 当创建对象的过程比较复杂或者消耗资源时，例如需要读取配置文件或者初始化大量数据。
2. 当你想在创建对象时提供一些额外的逻辑，例如缓存已经创建的对象或者返回一些特定的子类实例。
3. 当你想隐藏类的具体实现时，例如只提供一个接口或者抽象基类，并返回其具体子类的实例。

在C++中，工厂模式可以通过函数或者方法来实现。这里有一些例子：

工厂函数：

工厂函数是一个全局函数，它返回一个类的实例或者指针。例如：

std::unique_ptr<MyClass> createMyClass(int arg1, int arg2) {
    return std::make_unique<MyClass>(arg1, arg2);
}

在这个例子中，createMyClass是一个工厂函数，它接受两个参数并返回一个MyClass的unique_ptr。

工厂方法：

工厂方法是一个类的静态成员函数，它返回一个类的实例或者指针。例如：

class MyClass {
public:
    static std::shared_ptr<MyClass> create(int arg1, int arg2) {
        return std::shared_ptr<MyClass>(new MyClass(arg1, arg2));
    }

private:
    MyClass(int arg1, int arg2) {
        // Initialization logic
    }
};

在这个例子中，MyClass::create是一个静态工厂方法，它接受两个参数并返回一个MyClass的shared_ptr。注意MyClass的构造函数是私有的，这意味着用户只能通过create方法来创建MyClass的实例。

工厂模式的主要优点是它可以提供更多的灵活性和控制权。然而，它也有一些缺点，例如它可能使代码变得更复杂，而且如果类有许多可选参数，使用工厂模式可能会使代码变得难以阅读和理解。在选择是否使用工厂模式时，你应该根据你的具体需求来决定。

每个派生类创建不同的库

如果你打算为每个派生类创建不同的库，并且希望用户通过同一接口（基类）来使用它们，那么你可以使用“接口+工厂函数/方法”的方式。

假设我们有一个Animal基类和多个派生类（Dog, Cat, 等等），每个派生类都是单例。你可以在每个派生类中实现单例模式，并提供一个静态方法来获取该类的唯一实例。

然后，你可以在每个库中提供一个工厂函数，该函数返回基类的指针或引用。例如，对于Dog库，你可以提供以下工厂函数：

extern "C" Animal& createAnimal() {
    return Dog::getInstance();
}

在这个例子中，createAnimal函数返回Dog单例的引用。请注意，我们使用了extern "C"来确保函数的C链接，这样在动态加载库时就可以通过函数名来找到这个函数。

然后，用户可以动态加载你的库，并通过createAnimal函数来获取Animal的实例。例如，使用dlopen和dlsym函数（在dlfcn.h头文件中）：

#include <dlfcn.h>

// Load the library
void* handle = dlopen("/path/to/libDog.so", RTLD_LAZY);
if (!handle) {
    // Handle error
}

// Get the createAnimal function
typedef Animal& (*CreateAnimalFunc)();
CreateAnimalFunc createAnimal = (CreateAnimalFunc) dlsym(handle, "createAnimal");
if (!createAnimal) {
    // Handle error
}

// Use the Animal
Animal& myAnimal = createAnimal();
myAnimal.speak();  // Outputs "Woof!"

在这个例子中，用户动态加载了Dog库，并通过createAnimal函数获取了Dog的单例。尽管用户直接与Dog类交互，但他们只需要知道Animal接口，因此你的库仍然保持了多态性。

这种设计方式的优点是具有很好的灵活性和扩展性。你可以为每个动物类型提供一个库，用户可以选择加载哪个库，而不需要更改他们的代码。然而，它的缺点是需要用户动态加载库和查找函数，这可能会增加用户的使用复杂性。同时，你需要确保你的库在所有目标平台上都可用，因为动态加载库的方式在不同的平台上可能会有所不同。

建造者模式

建造者模式（Builder Pattern）是一种对象创建软件设计模式，它旨在找到一种解决方案来处理具有多个参数的对象，其中有些是必需的，有些是可选的。这种模式可以使得构造过程可以灵活地添加新的参数而不破坏已有的代码，使得代码更加易读易写。

一个典型的建造者模式实现包括以下几个部分：

1. Builder类：Builder类包含了创建复杂对象所需的所有步骤。Builder类通常是主对象的内部类，但也可以是独立的类。Builder类通常有一系列设置参数的方法（通常返回Builder自身以便于链式调用）和一个创建主对象的方法。
2. 主类：这是你希望用户创建的对象。通常，主类的构造函数是私有的或受保护的，只有Builder类可以访问。主类通常有一个静态方法来创建Builder类的实例。

下面是一个C++的建造者模式的示例：

class MyClass {
public:
    class Builder;

private:
    int param1;
    int param2;

    MyClass(int param1, int param2) : param1(param1), param2(param2) {}

public:
    class Builder {
    private:
        int param1;
        int param2;

    public:
        Builder& setParam1(int param1) {
            this->param1 = param1;
            return *this;
        }

        Builder& setParam2(int param2) {
            this->param2 = param2;
            return *this;
        }

        MyClass build() {
            return MyClass(param1, param2);
        }
    };
};

然后，用户可以使用如下方式来创建MyClass的实例：

MyClass obj = MyClass::Builder().setParam1(1).setParam2(2).build();

在这个例子中，MyClass::Builder是一个内部类，它有两个设置参数的方法（setParam1和setParam2）和一个创建MyClass实例的方法（build）。主类MyClass的构造函数是私有的，只有Builder类可以访问。

建造者模式的优点是可以使代码更加清晰，减少错误的可能性，特别是当对象有许多参数，或者构造过程复杂的时候。然而，它也会使代码更加复杂，增加了维护的难度。因此，你应该在需要时才使用建造者模式。

单例模式和多态

单例模式

可以直接为基类实现单例模式，用户可以通过获取基类的单例来使用你的库。例如：

class Animal {
public:
    static Animal& getInstance() {
        static Animal instance;
        return instance;
    }

    virtual void speak() const {
        std::cout << "Animal sound!\n";
    }

private:
    Animal() = default;  // private constructor
    Animal(const Animal&) = delete;  // no copy
    Animal& operator=(const Animal&) = delete;  // no copy assignment
};

然后，用户可以通过以下方式获取Animal的单例并使用它：

Animal& myAnimal = Animal::getInstance();
myAnimal.speak();  // Outputs "Animal sound!"

这种设计方式的优点是简单明了，用户只需要与一个类进行交互。然而，它的缺点是缺乏灵活性和扩展性。如果你在未来需要添加更多的动物类型，你可能需要重构你的代码以支持多态。

另外，值得注意的是，使用单例模式时需要特别小心。单例模式可能会导致代码之间的高度耦合，使得单元测试变得困难，并可能引发多线程问题。在选择使用单例模式时，你应该权衡其优缺点，并确保它适合你的需求。

多态的实现

如果你的设计需要通过基类来公开一个多态接口，那么你可以将基类设计为接口，即只包含纯虚函数，并不能直接实例化。然后提供一个或多个派生类的实现。用户只需要知道接口（基类），而具体实现（派生类）可以隐藏在库内部。这种方式被称为 “面向接口编程”。

例如，假设你有一个基类Animal，还有多个派生类Dog、Cat等。你可以这样设计：

class Animal {
public:
    virtual ~Animal() = default;
    virtual void speak() const = 0;
};

class Dog : public Animal {
public:
    void speak() const override {
        std::cout << "Woof!\n";
    }
};

class Cat : public Animal {
public:
    void speak() const override {
        std::cout << "Meow!\n";
    }
};

然后，你可以提供工厂函数或者工厂方法来创建特定的动物类型：

std::unique_ptr<Animal> createAnimal(AnimalType type) {
    switch (type) {
        case AnimalType::Dog:
            return std::make_unique<Dog>();
        case AnimalType::Cat:
            return std::make_unique<Cat>();
        // ...
    }
}

这样，用户就可以通过Animal接口和createAnimal工厂函数来使用你的库，而不需要知道具体的派生类：

std::unique_ptr<Animal> myAnimal = createAnimal(AnimalType::Dog);
myAnimal->speak();  // Outputs "Woof!"

这种设计方式的优点是具有很好的灵活性和扩展性。你可以在不改变Animal接口的情况下添加更多的动物类型，用户的代码也不需要做任何修改。同时，通过使用智能指针（例如std::unique_ptr或std::shared_ptr），你可以确保动态分配的对象能够正确地进行内存管理。

多态与单例模式的设计

以下是我从七个方面对这三种选择（基类为单例，派生类为单例，或两者都为单例）的分析：

1. 设计复杂性：
   • 基类为单例：设计相对简单，但可能限制了派生类的某些功能。
   • 派生类为单例：设计更复杂，需要在每个派生类中实现单例模式。
   • 都为单例：设计最复杂，需要在基类和所有派生类中都实现单例模式。
2. 代码重复：
   • 基类为单例：无需在每个派生类中都实现单例模式，可以减少代码重复。
   • 派生类为单例：可能需要在每个派生类中都实现单例模式，可能导致代码重复。
   • 都为单例：需要在基类和所有派生类中都实现单例模式，可能导致大量的代码重复。
3. 灵活性：
   • 基类为单例：灵活性较低，所有派生类都必须是单例。
   • 派生类为单例：灵活性较高，可以选择哪些派生类应该是单例。
   • 都为单例：灵活性较低，所有类都必须是单例。
4. 可扩展性：
   • 基类为单例：如果以后需要添加非单例的派生类，可能需要修改基类的设计。
   • 派生类为单例：可以很容易地添加新的单例或非单例派生类。
   • 都为单例：如果以后需要添加非单例的类，可能需要修改基类和所有派生类的设计。
5. 可维护性：
   • 基类为单例：只需要维护基类的单例实现。
   • 派生类为单例：需要维护所有派生类的单例实现。
   • 都为单例：需要维护基类和所有派生类的单例实现。
6. 内存使用：
   • 基类为单例：只需要存储一个基类的实例。
   • 派生类为单例：需要存储每个派生类的一个实例。
   • 都为单例：需要存储基类和所有派生类的实例。
7. 初始化控制：
   • 基类为单例：基类控制单例的创建，可以确保单例在使用前被正确初始化。
   • 派生类为单例：每个派生类都需要正确地初始化其单例。
   • 都为单例：基类和所有派生类都需要正确地初始化其单例。

方案一: 派生类为单例

如果派生类需要以单例形式存在，那么可以在该派生类中实现单例模式。然后你可以为用户提供一个方法，以获取该类的唯一实例的基类指针或引用。

假设我们有一个Animal基类和一个Dog派生类，Dog是一个单例，那么可以这样实现：

class Animal {
public:
    virtual ~Animal() = default;
    virtual void speak() const = 0;
};

class Dog : public Animal {
public:
    static Dog& getInstance() {
        static Dog instance;
        return instance;
    }

    void speak() const override {
        std::cout << "Woof!\n";
    }

private:
    Dog() = default;  // private constructor
    Dog(const Dog&) = delete;  // no copy
    Dog& operator=(const Dog&) = delete;  // no copy assignment
};

然后，用户可以通过以下方式获取Dog的单例并使用它：

Animal& myDog = Dog::getInstance();
myDog.speak();  // Outputs "Woof!"

请注意，因为单例模式需要控制类的实例化过程，所以Dog的构造函数是私有的，这阻止了用户直接创建Dog的实例。此外，为了防止复制Dog的实例，我们也禁用了复制构造函数和复制赋值运算符。所有这些都确保了Dog的单例性质。

这种设计方式的优点是你可以保持基类接口的多态性，同时为某些派生类提供单例的实例化方式。然而，它也有一个缺点，那就是用户不能直接创建派生类的实例，只能通过你提供的方法来获取实例。

如果你想在基类中持有一个指向派生类单例的引用（或者指针），那么你需要在基类中声明一个静态成员，类型是基类指针。

这里有一个例子，它展示了如何在基类中保存对派生类单例的引用：

class BaseClass {
public:
    static BaseClass* instance;  // Pointer to the singleton instance.

    BaseClass() {
        // Constructor can be called multiple times.
    }

    virtual void doSomething() = 0;  // Pure virtual function.
};

BaseClass* BaseClass::instance = nullptr;  // Initialize static member.


class SingletonDerived : public BaseClass {
public:
    static SingletonDerived& getInstance() {
        static SingletonDerived instance;  // Guaranteed to be destroyed, instantiated on first use.
        BaseClass::instance = &instance;   // Update the base class's pointer.
        return instance;
    }

    SingletonDerived(const SingletonDerived&) = delete;            // Delete copy constructor.
    void operator=(const SingletonDerived&)  = delete;            // Delete copy assignment operator.

private:
    SingletonDerived() {}                   // Make constructor private.
    ~SingletonDerived() {}                  // Make destructor private.

    void doSomething() override {
        // Implementation of the virtual function.
    }
};

在这个例子中，基类 BaseClass 有一个静态成员 instance，这是一个指向 BaseClass 的指针。当 SingletonDerived 的单例被创建时（即，当 getInstance 第一次被调用时），BaseClass::instance 被更新为指向 SingletonDerived 的单例。

这样，你就可以通过 BaseClass::instance 访问到派生类的单例。请注意，因为 instance 是基类指针，所以你只能通过它访问到基类的成员和虚函数，除非你将它强制转换为派生类指针。

如果你希望预先初始化好单例对象，并且确保用户在使用库时无需进行任何初始化步骤，这完全是可行的。在这种情况下，你可以使用静态初始化来创建单例对象。这种方法的好处是线程安全，并且保证了对象在首次使用之前就已经创建。

例如，对于Animal基类和Dog派生类，你可以这样实现：

class Animal {
public:
    virtual ~Animal() = default;
    virtual void speak() const = 0;
};

class Dog : public Animal {
public:
    static Dog& getInstance() {
        static Dog instance;
        return instance;
    }

    void speak() const override {
        std::cout << "Woof!\n";
    }

private:
    Dog() = default;
    Dog(const Dog&) = delete;
    Dog& operator=(const Dog&) = delete;
};

然后，在库内部，你可以创建一个全局的Animal引用，指向Dog的单例：

Animal& g_Animal = Dog::getInstance();

这样，Dog的单例就会在程序启动时自动创建，并且用户可以直接使用g_Animal，无需进行任何初始化。

请注意，这种方法的缺点是库内部的全局变量g_Animal对所有用户都是可见的，这可能会导致命名冲突。为了避免这种问题，你可以将全局变量放在命名空间中，或者提供一个函数来返回Animal的引用：

Animal& getAnimal() {
    return Dog::getInstance();
}

这样，用户可以通过调用getAnimal函数来使用Animal：

Animal& myAnimal = getAnimal();
myAnimal.speak();  // Outputs "Woof!"

这种设计方式的优点是简单易用，用户只需要调用一个函数就可以使用你的库。然而，它的缺点是缺乏灵活性，如果你在未来需要添加更多的动物类型，你可能需要更改你的库和用户的代码。

• 总结:

以上所述的都是在派生类中实现单例模式的方式。

1. 第一种方式是在派生类中实现单例模式，并提供一个静态的 getInstance() 方法来获取该单例。这种方式的优点是保持了基类接口的多态性，同时为某些派生类提供单例的实例化方式。但是，它的缺点是用户不能直接创建派生类的实例，只能通过 getInstance() 方法来获取实例。
2. 第二种方式是在基类中保持一个对派生类单例的引用或指针。这样，你就可以通过基类的静态成员来访问派生类的单例。这种方式的优点是可以在基类中统一管理所有派生类的单例，但是它的缺点是增加了基类和派生类之间的耦合度。
3. 第三种方式是在库内部创建一个全局的引用，指向派生类的单例。这样，用户可以直接使用这个全局的引用，而无需调用 getInstance() 方法。这种方式的优点是简化了用户的使用，但是它的缺点是全局的引用可能会导致命名冲突。

这些方式都有各自的优点和缺点，你可以根据你的需求和应用场景选择合适的方式来实现派生类的单例模式。

方案二:基类为单例

如果你的基类Animal也需要以单例形式存在，并且该基类会在一个库中被实例化为一个特定的派生类，那么你可以在基类中定义一个静态方法，该方法返回一个引用到该类的唯一实例。然后在派生类库中，你可以在全局范围内初始化该单例。

首先，你的基类可能看起来像这样：

class Animal {
public:
    virtual ~Animal() = default;
    virtual void speak() const = 0;

    // 允许设置Animal单例，只能设置一次
    static void setInstance(Animal* instance) {
        assert(!instance_ && "Instance already set!");
        instance_ = instance;
    }

    // 获取Animal单例的引用
    static Animal& getInstance() {
        assert(instance_ && "Instance not set!");
        return *instance_;
    }

private:
    static Animal* instance_;
};

// 初始化静态成员
Animal* Animal::instance_ = nullptr;

然后，在你的派生类库中，你可以在全局范围内创建一个派生类的实例，并将其设置为Animal的单例：

class Dog : public Animal {
public:
    void speak() const override {
        std::cout << "Woof!\n";
    }
};

// 创建Dog实例并设置为Animal单例
Dog g_Dog;
struct Initializer {
    Initializer() { Animal::setInstance(&g_Dog); }
} g_Initializer;

在这个例子中，g_Dog是Dog的一个实例，g_Initializer是一个全局对象，它在构造函数中将g_Dog设置为Animal的单例。因为全局对象在程序启动时就会被创建，所以Animal的单例会在程序启动时自动被设置。

然后，用户可以通过Animal::getInstance来获取Animal的单例：

Animal& myAnimal = Animal::getInstance();
myAnimal.speak();  // Outputs "Woof!"

这种设计方式的优点是用户只需要知道Animal接口，而不需要知道具体的派生类。然而，它的缺点是需要用户在每次使用Animal之前都调用getInstance，这可能会增加用户的使用复杂性。同时，你需要确保Animal的单例在用户开始使用之前就已经被设置，否则getInstance将会失败。

如果你希望在类的外部声明一个指针来持有单例对象的引用，那么这也是可以做到的。在这种情况下，你的基类和派生类可以不包含任何静态成员。然后，你可以在全局范围内声明一个指针，该指针用于保存单例对象的引你的基类和派生类可以像这样：

class Animal {
public:
    virtual ~Animal() = default;
    virtual void speak() const = 0;
};

class Dog : public Animal {
public:
    void speak() const override {
        std::cout << "Woof!\n";
    }
};

然后，你可以在全局范围内声明一个Animal指针，该指针用于保存单例对象的引用：

Animal* g_Animal = nullptr;

在你的派生类库中，你可以在全局范围内创建一个派生类的实例，并将其地址赋给g_Animal：

Dog g_Dog;
struct Initializer {
    Initializer() { g_Animal = &g_Dog; }
} g_Initializer;

在这个例子中，g_Dog是Dog的一个实例，g_Initializer是一个全局对象，它在构造函数中将g_Dog的地址赋给g_Animal。因为全局对象在程序启动时就会被创建，所以g_Animal会在程序启动时自动被设置。

然后，用户可以通过g_Animal来访问Animal的单例：

g_Animal->speak();  // Outputs "Woof!"

这种设计方式的优点是简单明了，用户可以直接使用g_Animal，无需调用任何函数。然而，它的缺点是g_Animal对所有用户都是可见的，这可能会导致命名冲突。为了避免这种问题，你可以将g_Animal放在命名空间中，或者提供一个函数来返回Animal的引用。同时，你需要确保g_Animal在用户开始使用之前就已经被设置，否则用户可能会访问到一个空指针。

上述方法都是介绍了如何在基类中实现单例模式，同时派生类不是单例的情况。具体来说：

1. 第一种方式是在基类Animal中设置和获取单例实例的静态方法，并在派生类库中全局初始化Animal的单例。这个设计方式的优点是，用户只需要知道Animal接口，而不需要知道具体的派生类。然而，它的缺点是需要用户在每次使用Animal之前都调用getInstance，这可能会增加用户的使用复杂性。
2. 第二种方式是在全局范围内声明一个指针，该指针用于保存单例对象的引用。这种设计方式的优点是简单明了，用户可以直接使用g_Animal，无需调用任何函数。然而，它的缺点是g_Animal对所有用户都是可见的，这可能会导致命名冲突。同时，你需要确保g_Animal在用户开始使用之前就已经被设置，否则用户可能会访问到一个空指针。

这些方式都有各自的优点和缺点，你可以根据你的需求和应用场景选择合适的方式来实现基类的单例模式。同时，你需要确保基类的单例在用户开始使用之前就已经被设置，否则可能会出现错误。

类内创建静态成员对象和类外声明指针的实例化方式对比

1. 简单性：
   • 类内静态成员：适中。需要在类内部正确处理单例模式。
   • 类外指针：简单。只需要一个全局指针和对象。
2. 封装性：
   • 类内静态成员：高。单例实例的所有相关处理都在类内部进行。
   • 类外指针：低。单例实例的处理在类外部进行。
3. 命名冲突：
   • 类内静态成员：低。通过类方法访问单例实例。
   • 类外指针：可能存在。全局指针在任何地方都可以访问。
4. 初始化控制：
   • 类内静态成员：高。类控制单例实例的创建时间和方式。
   • 类外指针：低。取决于全局对象的初始化顺序。
5. 线程安全：
   • 类内静态成员：高。可以通过Meyers’单例或call_once保证。
   • 类外指针：低。如果在运行时进行初始化，需要手动同步。
6. 内存管理：
   • 类内静态成员：自动。实例会在程序退出时被正确销毁。
   • 类外指针：自动。实例会在程序退出时被正确销毁。
7. 用户使用难易程度：
   • 类内静态成员：适中。用户必须调用特定的类方法来访问实例。
   • 类外指针：高。用户可以直接访问全局指针。