脆弱的基类是在每次讨论中都会出现的最常见的一点，在讨论中讨论了通过实现继承的可重用性。
除了常见的方形矩形示例之外，还有没有人遇到任何真正的问题。
每次我需要向某人解释这一点时，我会遇到一些现实世界的案例，这些案件引起了这些问题以及如何解决这个问题。
如果有人想分享他们对此的经验，那将非常有帮助。
这是一个了解此问题的维基百科链接
Fragile base class on wikipedia
我对此的投入...... 当基类版本发生更改时，问题通常发生，因为使用它的开发人员可能不知道基类实现发生的扩展，并且基类实现者可能没有关于所有派生类的所有必要细节。看似无害的更改可能会破坏所有派生类功能。无论如何，这是一个糟糕的设计实践，因为它会违反OCP原则。
“我们无法有时处理现代生活的复杂性，实际上是自然界中脆弱的基类问题的一个例子，原因是我们仍然继承了我们祖先的许多特征，这些特征导致了不同的生活。”
答案 0 :(得分：7)
是的 - java.util.Properties是一个很难得到的。
目前让我们抛开它从java.util.Hashtable派生的事实（这意味着它有get(Object)和put(Object, Object)，尽管属性总是字符串......
我曾经将java.util.Properties子类化为提供一种层次结构 - 在我拥有的属性文件中：
x.y.z = 10
a.b.c = 10
你可以问“x”的“master”属性（使用新的方法调用），它会给你另一个有效包含“yz = 10”等的属性对象。它可以方便地继承java.util .Properties尽可能多的其他代码段已经知道使用过的属性。如果它实现了一个接口，我就不会有子类，我也不会遇到任何问题：（
无论如何，我需要覆盖getProperty（）以在必要时引用回父属性。但有两个重载 - 我应该覆盖哪些？ getProperty（String）是否调用getProperty（String，String），反之亦然？也许我只需要覆盖get（）？它没有记录，如果我只覆盖其中一个，实现可能会在以后的版本中更改以切换事物 - 所以我需要覆盖它们。
其他各种方法也是如此（保存和加载是一种痛苦，IIRC--这是很久以前的事了）。基本上我可以更简单地完成这项工作，如果我可以依赖于不改变的属性的实现 - 但这显然会让Sun更难以在以后改进实现。
无论如何，这是一个明确的例子，其中组合和暴露客户端依赖的接口将更好地
。