如何实现RealNumber和ComplexNumber继承？

希望不是太学术...

假设我的SW库中需要实数和复数。

根据is-a（或here）关系，实数是复数，其中复数虚部中的b就是0。

另一方面，我的实现是，该子对象扩展父对象，因此在父对象RealNumber中，我将拥有实部，而子对象ComplexNumber将添加虚构图。

还有一种观点认为继承是邪恶的。

我记得像昨天一样，当我在大学学习OOP时，我的教授说，这不是继承的一个很好的例子，因为这两者的绝对值是用不同的方式计算的（但为此我们有方法重载/多态主义，对吗？）。 。

我的经验是，我们经常使用继承来解决DRY，因此，我们经常在层次结构中人工构造抽象类（由于名称不能代表真实世界中的对象，因此经常很难找到名称）。

即使从数学意义上讲，实数是复数，从复数导出实数也不是一个好主意。它违反了Liskov替代原则（其中包括），派生类不应隐藏基类的属性。

在这种情况下，实数将不得不隐藏复数的虚部。显然，如果只需要实数部分，则存储隐藏的浮点数（虚数部分）是没有意义的。

这基本上与注释中提到的矩形/正方形示例相同。

继承不是一个很好的例子，因为这两个的绝对值计算方式不同

实际上，这并不是反对所有继承的令人信服的原因，只是建议的class RealNumber<-> class ComplexNumber模型。

您可能会合理定义一个接口Number，该接口和接口都 将实现。RealNumberComplexNumber

可能看起来像

interface Number
{
    Number Add(Number rhs);
    Number Subtract(Number rhs);
    // ... etc
}

但是随后您希望将Number这些操作中的其他参数限制为与相同的派生类型this，您可以通过

interface Number<T>
{
    Number<T> Add(Number<T> rhs);
    Number<T> Subtract(Number<T> rhs);
    // ... etc
}

或者，您将使用允许结构多态性而不是子类型多态性的语言。对于数字的特定情况，您可能只需要能够重载算术运算符。

complex operator + (complex lhs, complex rhs);
complex operator - (complex lhs, complex rhs);
// ... etc

Number frobnicate<Number>(List<Number> foos, Number bar); // uses arithmetic operations

解决方案：没有公开RealNumber课

如果ComplexNumber使用静态工厂方法fromDouble(double)返回虚数为零的复数，我将完全可以。然后，您可以在该RealNumber实例上使用您将在该实例上使用的所有操作ComplexNumber。

但是我很难理解为什么您想要/需要一个公共的继承RealNumber类。通常，出于以下原因使用继承（在我的脑海中，如果错过了一些，请纠正我）

• 扩展行为。RealNumbers无法执行复数不能执行的任何额外操作，因此这样做毫无意义。

• 通过特定的实现来实现抽象行为。由于ComplexNumber不应该抽象，所以这也不适用。

• 代码重用。如果只使用ComplexNumber该类，则将重用100％的代码。

• 针对特定任务的更加具体/高效/准确的实现。这可以在这里应用，RealNumbers可以更快地实现某些功能。但是，此子类应该隐藏在静态对象的后面，fromDouble(double)并且不应在外部被知道。这样，就不必隐藏虚部。外面应该只有复数（实数是）。您还可以从产生实数的复数类中的任何操作返回此私有RealNumber类。（这假定类与大多数数字类一样是不变的。）

这就像实现一个称为零的Integer的子类，并对某些操作进行硬编码，因为它们对于零而言是微不足道的。您可以这样做，因为每个零都是整数，但是不要将其公开，而是将其隐藏在工厂方法后面。

说实数是复数在数学（尤其是集合论）中比计算机科学具有更多的意义。
在数学中，我们说：

• 实数是复数，因为复数集包括实数集。
• 有理数是实数，因为实数集包括有理数集（和无理数集）。
• 整数是有理数，因为有理数集包括整数集。

但是，这并不意味着您在设计包含RealNumber和ComplexNumber类的库时必须甚至应该使用继承。在有效的Java，第二版由约书亚布洛赫; 第16项是“继承时的有利组成”。为避免该项目中提到的问题，一旦定义了RealNumber类，便可以在ComplexNumber类中使用它：

public class ComplexNumber {
    private RealNumber realPart;
    private RealNumber imaginaryPart;

    // Implementation details are for you to write
}

这样，您就可以重用RealNumber类，使代码保持DRY，同时避免Joshua Bloch确定的问题。

这里有两个问题。首先，通常对容器的类型及其内容的类型使用相同的术语，尤其是对于诸如数字之类的原始类型。double例如，该术语用于描述双精度浮点值和可以存储一个值的容器。

第二个问题是，虽然is-a可以读取各种类型的对象的容器之间的关系与对象本身之间的关系相同，但是可以放置各种类型的对象的容器之间的关系与它们的内容之间的关系相反。每个已知拥有实例的Cat笼子都是拥有实例的笼子Animal，但不一定是拥有实例的笼子SiameseCat。另一方面，每个可以容纳的所有实例的笼子都是可以容纳的所有实例的Cat笼子SiameseCat，但不必是可以容纳的所有实例的笼子Animal。唯一一种可以容纳的所有实例Cat并且可以保证绝不容纳任何实例的笼子Cat，是的笼子Cat。任何其他种类的笼子要么不能接受Cat它应该接受的某些实例，要么能够接受不是实例的事​​物Cat。