部署后的基类设计更改

更新:2007 年 11 月

理想情况下,类层次结构部署后永不再更改,因为即使很小的更改都有产生意外后果的危险。在真实世界里,有时这种更改是无法避免的:产品要求可能会更改,而且有时设计规范会遗漏关键元素。有一类继承问题称为“脆弱的基类问题”。

脆弱的基类问题

使用继承层次结构的主要缺点是一种称为“脆弱的基类”的问题。 对基类的更改经常要求更改、重新编译和重新分发基类以及派生类中的所有代码。当多个开发人员创作基类和派生类时,此问题甚至更加困难,这是因为每一方都可能拒绝对他们的源代码的访问。最糟糕的情形是,客户可能无意中将已编译的二进制形式的更新基类与原始的不兼容二进制版本的派生类一起使用。

可能会破坏派生类的基类更改包括重写或更改基类成员的数据类型。

尽量避免脆弱的基类问题

避免脆弱的基类问题的最佳方法是仅在派生类中进行更改。但是,这种方法不是始终可行的,因为这要求您在第一次发布基类时要考虑到各种可能性;不管一个人如何努力,有时还是无法避免对基类进行不可预见的更改。

使用 MustInherit 类和 MustOverride 方法可以帮助减少脆弱的基类问题,因为这样做将实现的详细信息转移到了派生类中,从而减少了对更改基类的需要。但是,即使进行了最佳规划,此方法也不是始终可行的。

派生类中的阴影数据成员也是有帮助的,因为它们减少了与基类成员的命名冲突。

扩展基类功能的最安全的方法是添加新成员。新成员可能破坏基类的唯一方式是:派生类使用 Overloads 关键字从基类继承方法,并引入具有相同名称的新方法。可通过在派生类中显式指定要从基继承的基类方法来避免此问题,指定的方法是重新定义这些方法并对它们进行委托。

在某种意义上,所有基类在某种程度上都是脆弱的。总而言之,脆弱的基类问题无法消除,但可以通过仔细设计类层次结构而减少基类更改的需要,以及在这种更改不可避免时进行彻底的测试来尽最大可能避免该问题。

请参见

参考

Shadows

其他资源

设计继承层次结构