oop - 有人可以举一个脆弱的基类问题的更好例子吗？

Question

脆弱的基类是在每次讨论通过实现继承的可重用性的讨论中弹出的最常见的点之一。

除了常见的正方形、矩形示例之外，有没有人遇到过任何真正的问题。

每次我需要向某人解释这一点时，我都会遇到一些现实世界的案例，这些案例引发了这些问题以及如何解决。

如果有人想分享他们在这方面的经验，那将非常有帮助。

这是了解此问题的维基百科链接

Fragile base class on wikipedia

编辑:

我对此的投入...
问题主要发生在基类版本更改时，因为使用它的开发人员可能不知道基类实现发生的扩展，并且基类实现者可能没有关于所有派生类的所有必要细节。而看似无害的更改可能会破坏所有派生类的功能。无论如何，这是一个糟糕的设计实践，因为它会破坏 OCP 原则。

在软件旧论坛上从 Joel 那里得到了很好的报价。想把它放下。

“我们有时无法应对现代生活的复杂性，实际上是自然界中发生的脆弱基类问题的一个例子，原因是我们仍然从过着截然不同的生活的祖先那里继承了许多特征。”

Answer 1

是的 - java.util.Properties 是一个痛苦的派生。

暂时让我们抛开它从 java.util.Hashtable 派生的事实开始(这意味着它有 get(Object) 和 put(Object, Object) 尽管属性总是字符串......

我曾经将 java.util.Properties 子类化以提供一种层次结构 - 在我拥有的属性文件中:

x.y.z = 10
a.b.c = 10

并且您可以向“x”询问“主”属性(使用新方法调用)，它会为您提供另一个属性对象，该对象将有效地包含“y.z = 10”等。将 java.util.Properties 子类化为很方便许多其他代码已经知道使用的属性。如果它实现了一个接口(interface)，我就不会子类化，也不会有任何问题:(

无论如何，如有必要，我需要重写 getProperty() 以引用父属性。但是有两个重载 - 我应该覆盖哪个？ getProperty(String) 是否调用 getProperty(String,String) 或反之亦然？也许我只需要覆盖 get()？它没有记录，如果我只覆盖其中一个，实现可能会在以后的版本中更改以切换事物 - 所以我需要覆盖它们。

其他各种方法也是如此(保存和加载很痛苦，IIRC - 这是很久以前的事了)。基本上，如果我可以依赖 Properties 的一些实现不变，我可以更简单地完成这项工作 - 但这显然会使 Sun 在以后改进实现变得更加困难。

无论如何，这是一个明确的示例，其中组合和公开客户端将依赖的接口(interface)会好得多。