“既然说是脆弱，当然是指它象蛋壳一样不堪一击喽。这个问题其实很好理解。程序总是由人来设计与编写的，所以工作开始时考虑不到某些问题当然也是很正常的事。所以可能在工作进行了一段时间后发现基类需要变更。你想，如果我在基类中更改了成员的数据类型，以及那些允许重写的那些方法和属性，那派生类及其子类还能正常工作吗？尤其是当一个团队中的多个开发人员一起来创作基类和派生类时，就更是要命了。很多情况下，大家可能已经把基类和一些派生类编译成二进制形式进行提交了。更改基类，重新编译再分布，会牵一发而动全身，导致项目的崩溃。所以我们把这叫做‘脆弱的基类’。也就是说，它是整个工程中最薄弱最致命的环节。”大李眉头一直紧锁着，想必是回想起了自己受打击的经历。
“这么严重呀，现在的软件工程设计方法会不会对这个有很好的解决方案？”我努力想缓解一下大李的严肃神情。
“如果对项目的前期设计考虑尽可能周详，在工程实施中对项目的代码控制与相关性分析做得踏实，会起到很好的效果。但是不管一个人如何努力，有时还是无法避免对基类进行不可预见的更改。我们摸索过很久，有了一些处理的手段。”
“真是成事在人呀，我们现在有什么解决之道？”我也一下子振奋起来了。
“呵呵，并不是什么完美解决方案。只能在某种程度上减轻危害。我们常用的一个方法，最直接的思想就是，把有可能发生的更改全都放在派生类中进行，不在基类中做。”
“这具体是什么意思呀，我还是不太明白。”我不好意思地挠挠头。
大李微笑着点点头，看来是知道我不会明白的了。“我们在基类中使用的是抽象类，它内含的方法与属性只有定义，没有进行实现，而把实现部分都放在派生类中做。这样一来，抽象类自身是无法被实例化的。但是它的好处不言而喻，就是有可能发生的实现上的更改都会只涉及到它的派生类了。VB.NET中就提供了这样的手段。”
编缉推荐阅读以下文章
版权与免责声明
1、本站所发布的文章仅供技术交流参考，本站不主张将其做为决策的依据，浏览者可自愿选择采信与否，本站不对因采信这些信息所产生的任何问题负责。
2、本站部分文章来源于网络，其版权为原权利人所有。由于来源之故，有的文章未能获得作者姓名，署“未知”或“佚名”。对于这些文章，有知悉作者姓名的请告知本站，以便及时署名。如果作者要求删除，我们将予以删除。除此之外本站不再承担其它责任。
3、本站部分文章来源于本站原创，本站拥有所有权利。
4、如对本站发布的信息有异议，请联系我们，经本站确认后，将在三个工作日内做出修改或删除处理。
请参阅权责声明！