继承是设计建筑商/工厂的好工具吗?

Is inheritance a good tool to design a builder/factory

本文关键字：工具 工厂 建筑商 继承      更新时间：2023-10-16

我有几个复杂的类，它们是使用从要创建的类继承的单独创建者类构造的。

一个例子可能是从无序数据构造的图形。

class Graph{
  //....
  public:
   void showData(); 
  protected: 
    std::vector<std::pair<int,int> > mConnectedData;
}
class GraphCreator:private Graph{
  public:
    //...
    void construct();
  private:
   std::map<double,int> mSomeHelperContainer;
   //...
}

对于构造，我需要许多辅助函数和辅助数据，我将其放在另一个类 GraphCreator 中。由于许多与图相关的函数也是必要的，并且由于我在任何情况下都需要图的数据，因此我使用私有继承。由于这绝不是著名的is-a关系，并且由于私人继承通常被认为是糟糕设计的暗示，我有一些怀疑：这是一个好主意和设计工厂的一种适当方法，还是有一些我没有考虑过的主要缺点？设计这样一个工厂的更好方法是什么？

编辑：

感谢您到目前为止的回答！一些附加信息，使当前使用的方法的原因更加清晰。我不能使用静态创建方法（Creator 中的状态变量太多），我有另一个约束：我想在库中向其他人提供独立于创建者的图形（例如与从文件读取方法一起）。那些不应该关心创作者。因此，我也有点不确定朋友的用法，因为它在 Graph 类中添加了代码。

这不是

一个好方法（从任何有数据的东西继承很少是）。

传统方法是：

  • 让GraphCreator成为Graph friend
  • 在Graph中将该方法实现为static Build方法（直接）

决定主要取决于是否需要"工厂"是有状态的。class用于表示方法无法执行的状态。

  • 因此，如果您需要状态，则需要class来存储它，因此GraphCreator是您最好的选择。
  • 对于无状态方法，static方法要轻得多。

如果您犹豫不决，请选择最简单的（static方法），看看它能走多远:)

我从这里采用的经验法则是

尽可能使用组合，必要时使用私有继承。

"你必须"的一个具体例子是，当你从中继承的类有一些虚拟或纯虚函数时，你必须实现这些函数才能使用你的私有基础：如果不继承，你就无法做到这一点。

从你的描述来看，使用继承是不可避免的;因此，我认为最好使用组合。

相关文章：