1回顶部 由于最近接手了一个有关于ActiveX的产品的维护工作,使得我有机会重拾已丢下一年多的COM技术,同时也有机会重新审视技术的变迁历程,以及蕴含在其中的某些思想,这种感觉就好像回过头来看自己走过的道路。所不同 的是,回首自己的人生路,成败得失一幕了然;而技术的发展虽然依然遵循优胜劣汰的法则,但优劣之间的界限好像并不那么明显,反而有些使人迷茫。比如说复用。 2回顶部 然而,BLib库现在维护起来却好像并不轻松(也可能是我的水平有限)。在我看来,现在它具有几个明显的不足: 1、 由于是基于早期的ATL2.1发展而来,而目前流行的编程环境(VC6或者VC.NET)都已经不再支持ATL2.1了,因此BLib库不得不自己带上ATL2.1的源码,这看起来有些落伍。同时使得基于这个库的所有产品都无法轻易地迁移到更高版本的ATL上,因此无法直接从ATL的升级中受益。(即使现在已经是ATL7.0了,我还不得不想办法去搞ATL2.1的帮助文档。) 2、 由于要尽量支持复用,BLib库几乎对每个ATL中比较重要的部分都做了扩展。由于缺乏相应的文档,这使得阅读、维护这些代码成为了一件比较艰难的事情,很多时候那些扩展代码看起来与ATL中的代码只有一些细微的差别,使人很难理解。 3、 事实上,BLib库也并没有被真正的复用过。这个库建立的初衷也许就是为了以后的产品都基于这个库构建吧。但在这组ActiveX control产品建立的过程中,微软在98年推出了ATL3.0,这一下子使得这个库显得有些落伍。而发展出这个库的前辈们或者离开了公司,或者加入了别的项目,没有人来进行迁移工作。天长日久下来,后面的项目就都没有使用BLib库了。 在阅读和维护这些代码的过程中,我不由的总在想,Joshua Kerievsky说,在设计初期过多的考虑设计模式会引起过度设计。那么,在设计时过多的考虑复用性会不会引起过度设计呢?或者说,我碰到的这种情况算不算是一种过度设计呢?在我看来,如果不是过多的考虑了复用性,对于这样一组ActiveX control,完全没有必要发展一套库来完成,只需要使用ATL本身就能够完成了。这样,向更高版本的ATL迁移就不会成为一个问题。BLib库的维护成本是很高的(我的个人感受),如果是基于它做了很多产品,那么花些成本去维护是有意义的。然而只是一套产品,这个代价未免显得有些太高了。 因此,我有些迷惑了。代码的复用一直以来被我个人认为是设计编码过程中应当着重考虑的一个方面。因此,这些前辈们在开发产品的过程中基于复用的考虑发展一套库出来也是相当合理的做法,换作是我,我也会选择写一个库作为后续产品的基石的(也许会心有余而力不足L)。但是,发展一个库出来必然增加代码的维护难度,更何况这个库还是基于另外一个经常升级的库。从一个维护者的角度来看,我却宁愿代码少一些复用性,而多一些易维护性。毕竟我更关心如何快速理解程序中的逻辑,找出错误所在。这是一对矛盾,To be or not to be,我们该如何取舍呢?我们无法确知明天会怎样,我们今天写的代码,明天是否会被用在其他的地方。那么我们该如何确定复用对于我们代码的重要性呢?Refactoring to Patterns可以减少由Design Patterns引起的过度设计,那么有没有Refactoring to Reusable之类的方法,来减少由复用引起的过度设计呢? |
闂傚倸鍊搁崐宄懊归崶顒€违闁逞屽墴閺屾稓鈧綆鍋呭畷宀勬煛瀹€鈧崰鏍€佸☉妯峰牚闁告劗鍋撳В澶嬩繆閻愵亜鈧垿宕曢弻銉ュ瀭闁秆勵殔閽冪喖鏌i弮鍥モ偓鈧柛瀣尭閳藉鈻嶉褌绨奸柟渚垮姂瀹曟儼顦柡鈧懞銉d簻闁哄洨鍋為ˉ鐐烘倵濮樼偓瀚�闂傚倸鍊搁崐椋庣矆娓氣偓楠炴牠顢曢妶鍡椾粡濡炪倖鍔х粻鎴犲閸ф鐓曢柟閭﹀灱閸ゅ鏌ら弶鎸庡仴闁哄本绋戦埥澶娾枎閹邦喚鈻忕紓鍌氬€风拋鏌ュ疾閻樿钃熼柣鏃傗拡閺佸秵绻濇繝鍌氭灓闁哄棭鍘奸—鍐Χ閸愩劌濮烽梺鐟板殩閹凤拷>>
正在阅读:关于软件复用的思考关于软件复用的思考
2004-04-01 11:05
出处:CSDN
责任编辑:sdq