您能否提供当我们从一个类继承时的场景，它工作了一段时间，但随后发生了其他变化并引入了一个错误？ 我想出了以下情况：
如果我选择在 C# 中使用对象继承，我应该注意哪些其他问题。
【问题讨论】：
标签： c# inheritance oop
您所描述的是继承的陷阱之一。
另一个陷阱是深度继承层次结构。 composition over inheritance 上的 Stackoverflow 线程。
【讨论】：
对基类的更改可以通过多种方式影响派生类的行为。如果作者突然决定以sealed为例呢？
就像任何接口一样，如果消费者不需要修改，它就需要稳定。
继承的主要“规则”是里氏替换原则。这表明派生类应该可以替代基类或从它派生的其他类。
这个案例从表面上打破了这个规则，因为有孔的矩形不是矩形。
通常最好使用接口将行为划分为可实现的合理块。这种接口通常用形容词而不是名词命名。例如，对于要渲染的矩形和带孔的矩形都是有意义的，因此接口可能是IRenderable。如果它是可调整大小的，您可能有一个 IResizable 等。这些可以聚合成一个 IShape，但您要小心，您对 Shape 的定义只定义了您的问题域中的行为。
直接从另一个类派生可能很危险，因为您会受到该类行为的约束。如果您确实需要这样做，最好将您需要的实现提取到一个公共基类中（例如Rectangle : RectangleImplementation, IShape）。
【讨论】：
这被称为brittle base class problem。
一般来说，另一个潜在的继承问题是当您想使用自己的基类但框架需要特定的基类（例如，ContextBoundObject）而不是接口时。
【讨论】：
这就是有先见之明的 C# 语言设计者在语言中添加 sealed 关键字的原因。谨慎使用。
并使用代码契约来测试您的不变量，以获得有关损坏的早期警告。
【讨论】：
我认为这与 c# 或继承无关。不管你做什么，这都是软件开发不可避免的问题。
最好和简单的解决方案是每天构建您的代码并执行unit testing。
【讨论】：
在这些类型的情况下最好使用 -Decorator 模式。 这提供了更好的扩展方式。
这可以使用下图来实现：
矩形对象将被创建并包装到一个负责提供孔的 HoleDecorator 对象中。调整 Rectangle 的大小后，会调用 HoleDecorator 的 Resizing，这将首先调用 Rectangle 对象的 Resize，然后调用 Hole Decorator 的 AdditionalBehavior，它会指定当主组件被替换时要对孔做什么调整大小。
【讨论】：