VB.NET之旅（七）—脆弱的基类

VB.NET之旅（七）—脆弱的基类2012-09-01 Microsoft.com 韩睿“既然说是脆弱，当然是指它象蛋壳一样不堪一击喽。这个问题其实很好理解。程序总是由人来设计与编写的，所以工作开始时考虑不到某些问题当然也是很正常的事。所以可能在工作进行了一段时间后发现基类需要变更。你想，如果我在基类中更改了成员的数据类型，以及那些允许重写的那些方法和属性，那派生类及其子类还能正常工作吗？尤其是当一个团队中的多个开发人员一起来创作基类和派生类时，就更是要命了。很多情况下，大家可能已经把基类和一些派生类编译成二进制形式进行提交了。更改基类，重新编译再分布，会牵一发而动全身，导致项目的崩溃。所以我们把这叫做‘脆弱的基类’。也就是说，它是整个工程中最薄弱最致命的环节。”大李眉头一直紧锁着，想必是回想起了自己受打击的经历。

“这么严重呀，现在的软件工程设计方法会不会对这个有很好的解决方案？”我努力想缓解一下大李的严肃神情。

“如果对项目的前期设计考虑尽可能周详，在工程实施中对项目的代码控制与相关性分析做得踏实，会起到很好的效果。但是不管一个人如何努力，有时还是无法避免对基类进行不可预见的更改。我们摸索过很久，有了一些处理的手段。”

“真是成事在人呀，我们现在有什么解决之道？ ”我也一下子振奋起来了。

“呵呵，并不是什么完美解决方案。只能在某种程度上减轻危害。我们常用的一个方法，最直接的思想就是，把有可能发生的更改全都放在派生类中进行，不在基类中做。”

“ 这具体是什么意思呀，我还是不太明白。”我不好意思地挠挠头。

大李微笑着点点头，看来是知道我不会明白的了。“我们在基类中使用的是抽象类，它内含的方法与属性只有定义，没有进行实现，而把实现部分都放在派生类中做。这样一来，抽象类自身是无法被实例化的。但是它的好处不言而喻，就是有可能发生的实现上的更改都会只涉及到它的派生类了。VB.NET中就提供了这样的手段。”

说着，大李就打开VS.NET集成编译环境，顺手写了一小段代码：

Public MustInherit Class CBaseHenry    Public MustOverride Sub subX（ByVal x As Integer）    Public MustOverride Function fcnY（ByVal y As Integer） As Long  End Class  Public Class CDerivedHenry    Inherits CBaseHenry    Public Overrides Sub subX（ByVal x As Integer）      "写入实现的代码    End Sub    Public Overrides Function fcnY（ByVal y As Integer） As Long      "写入实现的代码    End Function  End Class

“这里要注意两个问题，一个是关键字，我们用 MustInherit来修饰类名，使类成为抽象类，在它的成员中，把方法和属性前加入 MustOverride修饰符表示它们必须在派生类中加以实现。第二个要注意的是，派生类必须对所有用MustOverride标识的基类方法和属性都进行实现，只重写了 subX，不写fcnY编译器会报错的。”

“这的确可以解决一部分问题，但好象只能解决在基类中进行实现的代码有更改的问题，对于数据类型的更改好象没有什么效果。”我看了好一会，发出了这样的疑问。

“所以我刚才说，是在某种程度上进行解决嘛。”大李也不由笑了起来，“不过你提的这个问题，倒不是太麻烦，我们可以在派生类中用 Shadows来解决呀！（详见本报上一期《重载与隐藏》）”