讨厌多重继承吗？

 private void runOrDont()
{
    if (this.battery)
    {
        if (this.battery.working && this.switchedOn)
        {
            this.run();
            return;
        }
    }
    this.dontRun();
}
 

#1 楼

在许多情况下，人们使用继承为类提供特征。例如，以飞马为例。通过多重继承，您可能会说飞马扩展了马和鸟，因为您已将鸟归为带翅膀的动物。

鸟具有佩加西所没有的其他特征。例如，鸟产卵，Pegasi有活产。如果继承是传递共有特征的唯一方法，那么就没有办法将飞蛋的特征排除在飞马之外。

一些语言选择使特征成为语言中的显式构造。他人会通过从语言中删除MI来轻轻地引导您朝该方向发展。无论哪种方式，我都无法想到“我确实需要MI才能正确完成此操作”的单个案例。

也让我们讨论一下真正的继承是什么。从类继承时，您需要依赖该类，但还必须支持该类支持的契约，包括隐式和显式。

以从a继承的正方形为例。长方形。矩形公开了length和width属性，还公开了getPerimeter和getArea方法。该正方形将覆盖长度和宽度，以便在设置一个时将另一个设置为与getPerimeter匹配，而getArea将起作用（2 * length + 2 * width表示周长，length * width表示面积）。

如果将正方形的这种实现方式替换为矩形，则只有一个测试用例会中断。

 var rectangle = new Square();
rectangle.length= 5;
rectangle.width= 6;
Assert.AreEqual(30, rectangle.GetArea()); 
//Square returns 36 because setting the width clobbers the length
 

用一个继承链就可以正确解决问题。当您将另一种添加到混合中时，情况变得更糟。


我在MI中用Pegasus提到的陷阱以及Rectangle / Square关系都是无经验的班级设计的结果。基本上，避免多重继承是一种帮助新手开发人员避免开枪的方法。像所有设计原则一样，根据这些原则进行纪律和培训可以使您及时发现何时可以脱离它们。请参阅Dreyfus技能习得模型，在专家级别，您的内在知识超越了对准则/原则的依赖。当规则不适用时，您可以“感到”。

我也同意，我在某种程度上欺骗了为什么MI被皱眉的“现实世界”示例。

让我们看一下UI框架。具体来说，让我们看一些小工具，这些小工具一开始可能看起来像是其他两个的组合。像ComboBox。 ComboBox是具有支持的DropDownList的TextBox。即我可以输入一个值，也可以从预先设定的值列表中进行选择。天真的方法是从TextBox和DropDownList继承ComboBox。

但是您的Textbox会从用户键入的内容中得出其值。当DDL从用户选择的内容中获得价值时。谁先行？ DDL可能被设计为验证和拒绝任何不在其原始值列表中的输入。我们会否重覆这种逻辑？这意味着我们必须公开内部逻辑，以便继承者可以覆盖。或更糟糕的是，将逻辑添加到仅用于支持子类的基类中（违反了依赖倒置原则）。

避免MI可以帮助您完全避开此陷阱。并可能导致您提取UI小部件的常见，可重用特征，以便可以根据需要应用它们。一个很好的例子就是WPF附加属性，它允许WPF中的框架元素提供一个属性，另一个框架元素可以使用该属性而无需继承父框架元素。

例如，网格是WPF中的布局面板，它具有附加的“列”和“行”属性，这些属性指定在网格的布局中应放置子元素的位置。没有附加属性，如果我想在Grid中安排一个Button，则Button必须从Grid派生，以便它可以访问Column和Row属性。

开发人员进一步采用了此概念，并使用了附加属性，作为组件行为的一种方式（例如，这是我在WPF包含DataGrid之前编写的使用附加属性制作可排序GridView的文章）。该方法已被认为是一种称为“附加行为”的XAML设计模式。

希望此方法提供了更多有关为何通常不赞成多重继承的见解。

#2 楼

我这里没有看到什么吗？


允许多重继承使有关函数重载和虚拟分派的规则以及对象布局周围的语言实现更加棘手。这些对语言设计者/实施者产生了很大的影响，并提高了本已很高的门槛，以使一种语言得以完成，稳定和被采用。

我看到（有时也提出过）另一个常见的论点是，通过拥有两个以上的基类，您的对象几乎总是违反单一责任原则。两个或两个以上的基类都是很好的自包含类，它们都有自己的责任（导致违规），或者它们是部分/抽象类型，它们相互协作以承担单个内聚的责任。

在其他情况下，您有3种情况：


A对B一无所知-太好了，您可以合并这些类，因为您很幸运。
A对B有所了解-为什么不知道t A只是继承自B？
A和B彼此了解-您为什么不参加一个班？个人认为，多重继承有一个不好的说唱力，而完善的特征样式组成系统真的很强大/有用。 。但是有很多方法可能无法很好地实现它，并且有很多原因使它在C ++之类的语言中不是一个好主意。

[edit]关于您的示例，这很荒谬。起亚有电子产品。它有一个引擎。同样，它的电子设备具有电源，恰好是汽车电池。继承，更不用说多重继承了。

#3 楼

禁止使用该工具的唯一原因是因为它使人们可以轻松地用脚射击自己。

在这种讨论中，通常接下来要讨论的是是否具有工具的灵活性比不踩脚的安全性更重要。该论点没有绝对正确的答案，因为与编程中的大多数其他事物一样，答案取决于上下文。

如果您的开发人员对MI感到满意，并且MI在您所了解的上下文中有意义正在这样做，那么您将以不支持它的语言非常怀念它。同时，如果团队对它不满意，或者没有真正的需求，而人们只是“因为他们有能力”使用它，那将适得其反。

但是，没有一个令人信服的绝对真实的论据证明多重继承是一个坏主意。

EDIT

这个问题的答案似乎是一致的。为了成为魔鬼的拥护者，我将提供一个多重继承的很好的例子，如果不这样做会导致黑客入侵。

假设您正在设计一个资本市场应用程序。您需要证券数据模型。有些证券是股票产品（股票，房地产投资信托等），有些是债券（债券，公司债券），有些是衍生产品（期权，期货）。
因此，如果您避免MI，您将获得非常清晰，简单的继承树。股票将继承股权，债券将继承债务。到目前为止还不错，但是衍生产品呢？它们可以基于类似股票的产品还是类似借方的产品？好的，我想我们将使继承树更多。请记住，某些衍生产品基于股票产品，债务产品或两者都不基于。因此我们的继承树变得越来越复杂。
然后是业务分析师，告诉您现在我们支持指数证券（指数期权，指数期货期权）。这些东西可以基于权益，债务或衍生工具。这越来越混乱了！我的指数期货期权会衍生股本->股票->期权->指数吗？为什么不选择股票->股票->指数->期权？如果有一天我能在我的代码中找到两者（发生；这是真实的故事）怎么办？

这里的问题是，这些基本类型可以混合在任何不能自然地从另一个中派生的置换中。对象是通过关系定义的，因此合成毫无意义。多重继承（或mixin的类似概念）是这里唯一的逻辑表示。

解决此问题的真正方法是使用多重继承定义和混合Equity，Debt，Derivative，Index类型。创建您的数据模型。这将创建既有意义又易于代码重用的对象。

#4 楼

这里的其他答案似乎主要是理论上的。因此，这是一个简化的具体Python示例，实际上我已经彻底陷入其中，需要大量重构：

 class Foo(object):
   def zeta(self):
      print "foozeta"

class Bar(object):
   def zeta(self):
      print "barzeta"

   def barstuff(self):
      print "barstuff"
      self.zeta()

class Bang(Foo, Bar):
   def stuff(self):
      self.zeta()
      print "---"
      self.barstuff()

z = Bang()
z.stuff()
 

编写Bar时假设它具有自己的zeta()实现，这通常是一个很好的假设。子类应该适当地重写它，以便正确执行操作。不幸的是，它们的名称恰好是相同的-所做的事情却大不相同，但是Bar现在调用了Foo的实现：

foozeta
---
barstuff
foozeta

没有引发任何错误，该应用程序开始执行操作时只是出现了一点点错误，并且导致它的代码更改（创建Bar.zeta）似乎并不是问题所在。

#5 楼

我认为使用正确语言的MI并没有任何真正的问题。关键是允许菱形结构，但要求子类型提供其自己的覆盖，而不是编译器根据某些规则选择一种实现。

我用番石榴（Guava）来做这件事正在努力。 Guava的一个功能是我们可以调用方法的特定超类型的实现。因此，很容易指出应该“继承”哪个超类型实现，而无需任何特殊语法：

type Sequence[+A] {
  String toString() {
    return "[" + ... + "]";
  }
}

type Set[+A] {
  String toString() {
    return "{" + ... + "}";
  }
}

type OrderedSet[+A] extends Sequence[A], Set[A] {
  String toString() {
    // This is Guava's syntax for statically invoking instance methods
    return Set.toString(this);
  }
}

如果我们不给OrderedSet自己的toString，我们将得到编译错误。毫不奇怪。

我发现MI对集合特别有用。例如，我喜欢使用RandomlyEnumerableSequence类型来避免为数组，双端队列等声明getEnumerator：

type Enumerable[+A] {
  Source[A] getEnumerator();
}

type Sequence[+A] extends Enumerable[A] {
  A get(Int index);
}

type RandomlyEnumerableSequence[+A] extends Sequence[A] {
  Source[A] getEnumerator() {
    ...
  }
}

type DynamicArray[A] extends MutableStack[A],
                             RandomlyEnumerableSequence[A] {
  // No need to define getEnumerator.
}

如果我们没有MI，我们可以编写一个供多个集合使用的RandomAccessEnumerator，但是必须写一个简短的getEnumerator方法仍然会增加样板。

类似地，MI对于继承集合的equals，hashCode和toString的标准实现很有用。 >

#6 楼

继承（无论是多重继承还是其他继承）并不那么重要。如果两个不同类型的对象是可替换的，那么即使没有通过继承链接它们也很重要。

链接列表和字符串的共同点很少，不需要通过继承链接。 ，但是如果我可以使用length函数来获取任一元素中的元素数量，则很有用。

继承是避免重复执行代码的一种技巧。如果继承可以节省您的工作，并且多重继承比单继承可以节省更多的工作，那么这就是所有需要的理由。

我怀疑某些语言不能很好地实现多重继承，并且对于那些语言的从业者来说，这就是多重​​继承的意义。提到C ++程序员的多重继承，我想到的是一个类通过两个不同的继承路径最终获得两个基类的副本时是否出现问题，以及是否在基类上使用virtual，以及关于析构函数的困惑

，在许多语言中，类的继承与符号的继承混为一谈。当从类B派生类D时，不仅要创建类型关系，而且由于这些类还充当词法命名空间，因此，除了将符号从B名称空间导入D名称空间外，还要处理符号输入。 B和D本身发生的情况的语义。因此，多重继承带来了符号冲突的问题。如果我们从card_deck和graphic继承，它们都“拥有” draw方法，那么对产生的对象draw意味着什么？没有此问题的对象系统是Common Lisp中的对象系统。 Lisp程序中可能使用了多种继承，这可能并非偶然。

实施不佳，不便之处（例如多重继承）应该受到仇恨。

#7 楼

据我所知，部分问题（除了使您的设计更难以理解（尽管更易于编写代码））是编译器将为类数据节省足够的空间，从而使在以下情况下会浪费内存：

（我的示例可能不是最好的，但是出于相同的目的，尝试获取有关多个内存空间的要点，这是我想到的第一件事： P）

考虑当班犬从犬类和宠物中伸出的DDD时，犬类具有一个变量，该变量指示应以DietKg为名食用的食物量（整数），但宠物也可以为此，通常使用相同的名称来具有另一个变量（除非您设置另一个变量名称，否则您将编写额外的代码来处理和保持bouth变量的完整性，这是您想避免的最初问题），然后您将有两个用于完全相同目的的内存空间，为避免这种情况，您将必须修改compi可以在相同的名称空间下识别该名称，并只为该数据分配一个内存空间，不幸的是，在编译时必须确定该空间。

您当然可以设计一个languaje来指定这样的变量可能已经在其他地方定义了空间，但是最后程序员应该指定该变量所引用的内存空间在哪里（还有额外的代码）。

请相信实现的人们这个想法真的很难，但是我很高兴你问，你的前提是改变范式的那个；），并考虑到这一点，我并不是说这是不可能的（但是许多假设和一个多阶段编译器必须实施，而且非常复杂），我只是说它还不存在，如果您为自己的编译器启动一个能够执行“ this”（多重继承）的项目，请告诉我，我很高兴加入您的团队。

#8 楼

相当长一段时间以来，我从未真正想到某些编程任务与其他编程任务有多么完全不同，如果所使用的语言和模式是针对问题空间量身定制的，这对您有多大帮助。

是单独工作还是与您编写的代码基本隔离，这是一个完全不同的问题空间，它是从印度的40个人那里继承了一个代码库而来的，这个人花了一年的时间才将代码库交给您，而没有任何过渡帮助。

想象一下，您刚刚被梦想中的公司雇用，然后继承了这样的代码库。进一步假设，顾问们已经学习了继承和多重继承（并因此而对其产生了浓厚的兴趣）……您能想象一下您将要从事的工作吗？

当您继承代码时，最重要的功能是这是可以理解的，并且各个部分是隔离的，因此可以独立进行处理。当然，当您第一次编写诸如多重继承之类的代码结构时，可能会节省一些重复时间，并且似乎符合您当时的逻辑心情，但是下一个人有更多东西需要解决。您的代码中的代码也使独立理解和修改代码变得更加困难，而多重继承则使它加倍。

当您作为团队的一员工作时，您希望以最简单的代码作为目标，从而为您提供绝对的没有多余的逻辑（这就是DRY的真正意思，不是说您不必键入太多就不必在两个地方更改代码来解决问题！）

有更简单的方法可以实现DRY代码比多重继承更重要，因此将其包含在一种语言中只会使您面临其他人可能与您的理解水平不高的问题。如果您的语言无法为您提供使代码保持DRY的简单/不太复杂的方法，这甚至很诱人。

#9 楼

反对多重继承的最大论点是，在严格限制它（*）的框架中，可以提供一些有用的能力，并且可以保留一些有用的公理，但没有这样的限制就不能提供和/或保持。其中包括：具有多个单独编译的模块的功能包括从其他模块的类继承的类，并重新编译包含基类的模块而不必重新编译从其继承的每个模块。该基类。
一种类型可以从父类继承成员实现而无需重新实现派生类型的能力
任何对象实例都可以直接向上或向下转换到其自身的公理或其任何基本类型，并且这种上下转换（以任何组合或顺序）始终保持身份
的公理，即派生类重写并链接到基类成员时，基类将是

（*）通常，通过要求将支持多重继承的类型声明为“接口”而不是类，并且不允许接口进行操作，通常不会通过链接代码进行调用。普通班可以做的一切。
如果希望允许广义多重继承，则必须让位。如果X和Y都继承自B，则它们都覆盖同一个成员M并链接到基本实现，并且如果D继承自X和Y但不覆盖M，则给定实例q的类型D，应该是什么（（ B）q）.M（）吗？禁止进行这种强制转换会违反说任何对象都可以转换为任何基本类型的公理，但是强制转换和成员调用的任何可能行为都会违反关于方法链接的公理。可以要求仅将类与针对它们编译的基类的特定版本组合加载，但这通常很尴尬。让运行时拒绝加载可以通过一条以上路径到达任何祖先的任何类型的方法可能是可行的，但会大大限制多重继承的用处。仅当不存在冲突时才允许共享继承路径会导致以下情况：旧版本的X与旧的或新的Y兼容，旧的Y与旧的或新的X兼容，但新的X和新的Y将兼容兼容，即使它们本身并没有任何重大改变。

某些语言和框架确实允许多重继承，因为从MI中获得的收益更重要超过必须放弃的范围。但是，MI的成本是巨大的，并且在许多情况下，接口以很小的一部分成本即可提供90％的MI收益。

评论

---

不赞成投票的人会发表评论吗？我相信我的答案提供了其他语言无法提供的信息，这些信息涉及可以通过禁止多重继承获得的语义优势。允许多重继承将需要放弃其他有用的事实，这将是一个比多重继承更看重其他事物的人反对MI的充分理由。

–超级猫
2014年8月3日在18:54

---

使用与单继承相同的技术，可以轻松解决或完全避免MI问题。除了第二个，您所提到的所有能力/原则都不是MI固有的阻碍因素...并且，如果您要继承两个为同一方法提供不同行为的类，则无论如何要解决这种歧义。但是，如果您发现自己必须这样做，则可能已经在滥用继承。

– cHao
15年5月26日在15:07

---

@cHao：如果要求派生类必须重写父方法并且不链接到父方法（与接口相同的规则），则可以避免这些问题，但这是一个非常严格的限制。如果使用一种模式，其中FirstDerivedFoo的Bar替代行为只不过链到了受保护的非虚拟FirstDerivedFoo_Bar，而SecondDerivedFoo的替代链则保护了非虚拟SecondDerivedBar，并且如果要访问基本方法的代码使用了这些受保护的非虚拟方法，这可能是一个可行的方法...

–超级猫
15年5月26日在15:47

---

...（避开语法base.VirtualMethod），但是我不知道任何语言支持会特别促进这种方法。我希望有一种干净的方法可以将一个代码块附加到非虚拟受保护方法和具有相同签名的虚拟方法上，而无需“单线”虚拟方法（最终需要花费多于一行代码）在源代码中）。

–超级猫
15年5月26日在15:52

---

MI没有内在的要求，即类不能调用基本方法，也不需要特定的理由。考虑到该问题也会影响SI，因此怪罪MI似乎有点奇怪。

– cHao
15年5月26日在17:56

---