有人可以提供脆弱基类问题的更好例子吗？

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

除了常见的方形,矩形示例之外,有没有人遇到任何真正的问题.

每次我需要向某人解释这一点时,我会遇到一些现实世界的情况,这些问题引起了这些问题以及如何解决这个问题.

如果有人想分享他们对此的经验,那将非常有帮助.

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

维基百科上的脆弱基类

编辑:

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

在软件旧论坛上得到了Joel的好评.把它放下来的想法.

"我们无法有时处理现代生活的复杂性,实际上是自然界中脆弱的基类问题的一个例子,原因是我们仍然继承了我们祖先的许多特征,这些特征导致了不同的生活."

是的 - java.util.Properties是一个很难得到的.

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

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

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

你可以问"x"的"主"属性(使用新的方法调用),它会给你另一个有效包含"yz = 10"等的属性对象.将java.util.Properties子类化为许多其他代码已经知道使用过的属性.如果它已经实现了接口,我就不会有子类,我也不会有任何问题:(

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

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

无论如何,这是一个明确的例子,其中的组成和暴露哪些客户端将依靠本来的接口多好.