继承与聚合以及“has-a”与“is-a”相对。

Question

在我的代码中，我发现使用类似 mixin 的继承来组合具有不同块的对象很有用。我有：

class Name
{
public:
    typedef int32_t value_type;

public:
    // ctors and dtors
    void set_value(value_type value) { value_ = value; }
    const value_type& value() const { return value_; }

private:
    value_type value_;
};

class NamedObject
{
public:
    void set_name(const Name& name) { name_ = name; }
    const Name& name() const { return name_; }

protected:
    // ctors and dtors

private:
    Name name_;
};

并且我使用这种基类来为对象提供具有预定义非虚拟功能的属性：

class MyObject: public NamedObject, public HasZlevel {
  // functionality that is not connected with NamedObject and HasZLevel
};

因此，我决定将 MyObject 视为“is-a”NamedObject，而不是“has-a”Name。 Z-level 和 Name 是在 MyObject 实例的生命周期内永远不会改变的属性。与聚合相比，我更喜欢这种方法，因为在仅为 NamedObjects 定义的算法中简化了使用，或者对于具有 HasZLevel 接口的对象，我可以通过 NamedObject* 或 HasZLevel* 传递它们，并确保它们不会因受保护而被删除或附加博士和演员。

另一个选项是聚合：

class MyObject
{
public:
    MyObject(const Name& name): name_(name) {}
    void set_name(const Name& name) { named_->set_name(name) }

    // and so on...

private:
    Name name_;
};

要使用它，我需要模板算法，该算法要求参数类型具有 set_name 成员函数。

在我的例子中，有什么充分的理由放弃类似 mixin 的设计并使用聚合吗？也许是为了长期维护和改装？

Answer 1

因为多重继承很糟糕。

这就是我喜欢胶带的原因
程序员。有时，你在一个
团队，而你正忙着敲打
代码，有人找到你的
办公桌上，手里拿着咖啡杯，然后开始
喋喋不休地谈论如果你如何使用
多线程 COM 公寓，您的
应用程序将会更加闪亮 34%，而且
甚至没有那么难，因为他
写了一堆模板，等等
你要做的就是乘法继承
来自他的 17 个模板，每个模板都取自
平均 4 个参数，而你
几乎不需要写正文
的功能。这只是一个巨大的
多重继承列表
不同的班级，嘿，快点，
多单元线程 COM。还有你的
眼睛在游动，而你却没有
该死的知道这个家伙是什么
正在谈论，但他就是不去
离开，即使他真的离开，
他正要回办公室
写更多他的聪明课程
完全由多个构造而成
从模板继承，没有
根本只有一个实施机构，并且
它会疯狂地崩溃
你会在晚上接到传呼
进来并尝试找出答案
因为他会在某个该死的
“设计模式”聚会。

管道胶带程序员并不害怕说：“多重继承很糟糕。停止吧。停下来吧。”

简而言之：这真的会帮助您更快地交付代码吗？或者，当某些重写的成员函数阻塞继承树上的其他成员时，您将在调试器中调试多重继承的类并单步执行超类的棘手问题，这会花费更多的时间吗？

是的，我确实写了“让会员窒息”。多重继承确实有那么糟糕。

Answer 2

经验法则是“尽可能使用最弱的关系”。看看：http://www.gotw.ca/publications/mill06.htm 和 http://www.gotw.ca/publications/mill07.htm

您可以使用私有继承来建模“is-implemented-in-term-of”，但您应该考虑异常安全含义 http://www.gotw.ca/gotw/060.htm

我知道，我喜欢本周的大师。 ;-)

编辑

我使用这种基类来
为对象提供属性
预定义的非虚拟功能

为什么聚合比继承更好：

1）您可以通过继承隐藏方法（或更改名称），默认情况下所有方法都可用。

2) 您可以使用带有非虚拟析构函数的类（std::string 和所有 stl 容器）。

3）您可以轻松更改实现，如果您想更改底层对象，您的接口将保持不变，但是如果您从不同的基类继承，您的接口可能会更改。

4）异常安全（参见第三个链接）。

5）易于阅读。

当需要“私有继承”时：

1）当您要使用的类是抽象类时（不能使用聚合）。

2）当你想使用受保护的方法时。

当需要“公共继承”时：

1）当您想要访问私有方法和数据时（您不应该这样做）。

最后，聚合可以让您更好地控制界面。我通常更喜欢这个选项。私有继承有时是唯一的选择，但代价是接口更加严格，并且还会影响异常安全。我尽量避免使用私有继承。

我从未使用公共继承来建模“has-a”。

Answer 3

问题是，如果您像在这里所做的那样公开继承，那么有时，某个地方，有人会将您的类视为 NamedObject 或 HasZlevel 并尝试由父级删除指针、传递它等等。这可能不会太好。

如果你想使用这样的 mixin 类型策略，至少使用 private 继承，然后 using 你需要的父方法到各个子类的公共部分（ es）。

但我并不特别建议这样做。如果您使用继承来表示替换，那么您的基类表示一个接口，而不是功能。我想说在这种情况下使用组合更有意义。整个标准库都是基于通用（模板）算法的，所以我不会处理这个问题。独立的模板算法方法是扩展代码的好方法，而无需修改类内部结构，甚至其公共接口。

Answer 4

多重继承的主要问题是，有人会尝试将一个人建模为从“手臂”和“腿”继承，然后抱怨多重继承混淆了问题。

Mixins 来自 Lisp 世界，我从来不相信它们那么适合 C++。然而，多重继承本身并不是邪恶的，而且可能是必要的。某事物与多个事物具有“是”关系是很常见的。

根据经验，我尝试仅使用空基类，即 Java 所谓的接口。如果我在基类中需要任何类型的数据，我几乎总是发现我的设计与尝试将人员类定义为继承自“arm”和“leg”一样糟糕。也有例外，如果您相信自己已经找到了例外，请尝试编写一份文档并请一些朋友对其发表评论。经验法则并不是正式的数学证明，但它对我来说非常有用。

Answer 5

正如几乎所有人所说，那些多重继承对象是可怕的、可怕的和无用的。

我认为您问自己错误的问题，或者，我如何确保我的代码可以在编译时进行静态检查。

您应该问的第一个问题是：我需要在实施决策中隐藏哪些细节。

你在哪里使用这些悲伤的物品？他们在建模什么？

Answer 6

有一种方法可以通过将我的使用模式转换为以下方式来避免多重继承：

template<class T>
class Named: public T {
  // all for named object
};

template<class T>
struct NamedCompare {
  bool operator<const Named<T>* obj1, const Named<T>* obj2) {
    //...
  }
};

template<class T>
class NamedSet {
  typedef std::set<NamedSet<Named<T>*, NamedCompare> type;
};

bool DoSmthWithFoo(Param1 p1,..., NamedSet<Foo>::type& set);

因此，我可以以某种方式创建所需功能的对象

typedef Named<Featured<Blabla<Foo> >  > NamedFeaturedBlablaFoo;

，或者

class NamedFeaturedBlablaFoo: public Named<Featured<Blabla<Foo> >  > {};

是否可以使用默认构造函数来防止编译器日志污染。

我看到的主要优点 - 我可以划分不同属性的功能并为许多类使用划分的块。此外，我做了一些类似的概念，这意味着我明确定义了我在模板函数中使用的对象。

我看到一个从具体类继承的设计漏洞，但这需要解释它实际上如何威胁我的代码。
另一个问题是隐藏 Foo 类的 typedef（如果它是模板），并且我看不出有什么方法可以解决它。
这段代码闻起来很糟糕......

我可以以相同的方式声明 NamedCompare 和 NamedSet，但没有命名使用，只需从 T 调用 name() 即可。这将起作用，我可以在独立算法中使用它。我认为它比这些 mixin 好得多。