"Modern C++ Design"文档管理器的设计是否正确？

Is "Modern C++ Design" DocumentManager design correct?

本文关键字：是否 Modern C++ Design 文档 管理器      更新时间：2023-10-16

我正在翻阅《现代C++设计》一书，我看到了"8.1 对象工厂的必要性"中解释的以下代码，我有一些疑问。

  1. 我的理解是，每次编写派生文档类时，都应该在新的派生文档管理器类中覆盖"CreateDocument（）"？
  2. 如果是，那么将有太多的派生文档管理器，需要自己的工厂方法!!

  3. 如果否，则"CreateDocument（）"应该采用一个ID，以便它可以准确地决定在对象中创建什么。但这也意味着，每次创建派生文档时，他也应该找到正确的 documentManager 并更新 CreateDocument（） 方法。但是我们必须决定是否拥有文档管理器工厂，因为它们可能很少或很多。

    我

    的主要疑问是这是否是一个解决方案，或者我是否错过了重点。根据这本书，CreateDocument()是GoF书的工厂方法。"CreateDocument（）"基于ID和许多条件创建一个新的派生文档至少是有意义的。但是很多派生的DocumentManager没有意义。

DocumentManager书中，

class DocumentManager
{
    ...
public:
    Document* NewDocument();
private:
    virtual Document* CreateDocument() = 0;
    std::list<Document*> listOfDocs_;
};
Document* DocumentManager::NewDocument()
{
    Document* pDoc = CreateDocument();
    listOfDocs_.push_back(pDoc);
    ...
    return pDoc;
}

客户端代码：

Document* GraphicDocumentManager::CreateDocument()
{
    return new GraphicDocument;
}

更新：您的问题经过大量编辑，以使其具有不同的重点。 还有几点：

  • 您似乎认为任何提及"工厂"的内容都必然涉及一个接受某些输入的具体函数，并根据输入吐出许多可能的动态类型之一的实例。 这只是一种工厂类型，而不是代码中提供的类型。

阅读工厂方法模式，希望您能意识到这就是您所拥有的。 它允许您执行以下操作：

std::string compress(DocumentManager& d, const std::string& uncompressed)
{
    std::unique_ptr<Document> doc = std::make_unique(d.NewDcoument());
    doc = uncompressed;  // interpret to form document of whatever type
    return zlib::compress(d.data(), d.size());  // compress as binary blob
}

在这里，可以使用一些原始输入调用 one compress() 函数，并尝试首先创建一个正确调用者指定类型的文档，然后将一些数据填充到其中并压缩它。

工厂方面是压缩在不知道所涉及的具体类型的情况下创建对象的能力，因为 - 非模板化且缺乏任何切换 - 否则它无法在许多构造函数之间进行选择。

基于原始问题的答案...

我们不是将对象创建的问题从Document转移到DocumentManager类吗？我的意思是我们必须创建[具体的]DocumentManager？

这就是重点不是吗 - 围绕创建特定类型的Document进行额外的记录保存（在这种情况下是list<Document*>）。

如果我们让客户端代码直接创建Document，那么拥有这样的列表将取决于客户端每次创建对象时更新列表（或需要对Document构造函数进行侵入性更改）。 如果我们想说在创建对象时添加时间戳，我们必须修改客户端代码中创建任何类型的Document的每个位置。

如果我们没有DocumentManager基类，我们将不得不将类似的逻辑和数据成员放入任意数量的GraphicDocumentManager、TextDocumentManager、AudioDocumentManager等中，并且无法多态地处理这些管理器（例如创建一个vector<DocumentManager*>，编写函数ala void f(DocumentManager&);。

如何跟踪由许多独立客户端创建的所有派生类DocumentManager？

设计中没有任何内容旨在执行此操作，并且C++没有允许您枚举派生类型的内省设施 - 无论是在编译时还是在程序开始运行时。 但是，如果您准备等待调用NewDocument，您可以记录具体DocumentManager派生对象的地址和/或访问它们的 RTTI 信息（例如，让您计算已创建的不同类型的文档，或尝试显示动态类型的实现定义（可能为空）name()字段......

listOfDocs_不应该是静态的，而文档管理器不应该是单一实例。

应该不会。 程序可能想要做一些事情，比如为每个TCP客户端，每个文件系统，每个用户等保留一个DocumentManager对象 - 那么为什么要不自然地限制它呢？ 最好是制作一个更灵活的DocumentManager类型，然后让客户端代码应用单例包装器（例如，返回static实例的函数），如果这对它们确实有用的话。 这也使测试更容易：您可以自由创建DocumentManager，运行测试，让析构函数运行，创建另一个等等。

我

的主要疑问是，这是否是一个解决方案，或者我错过了某些点。

似乎你错过了一些"位图片"，但没有书或你更一般的问题/理解陈述，很难知道它还能是什么。

根据这本书，"CreateDocument（）"是GoF书的工厂方法。但我无法理解以上几点。

是的 - 这是一个工厂方法，因为它创建许多不同动态类型的对象中的任何一个，但返回一个指向基类的指针，通过该指针可以多态地处理它们。

  1. 我们不是将对象创建的问题从Document转移到DocumentManager类吗？我的意思是我们必须创建音乐会DocumentManager吗？我们如何跟踪由如此多的独立客户端创建的所有派生类DocumentManager？

    • CreateDocument是工厂方法。 DocumentManager不负责创建对象。 派生管理器（GraphicDocumentManager）的CreateDocument将以其特定的方式创建文档。

  2. listOfDocs_不应该是静态的，DocumentManager是单例吗？

      是的，
    • 我想是的。理想情况下不能有两个经理类。但我不知道派生类的单例的复杂性。
    3. 我

  3. 的主要疑问是是否有解决方案，或者我是否错过了重点。 根据这本书，CreateDocument()是GoF书的工厂方法。但我无法理解以上几点。

    • 这只是工厂方法。

请阅读此链接：http://www.codeproject.com/Articles/35789/Understanding-Factory-Method-and-Abstract-Factory

相关文章：