|
然而，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之类的方法，来减少由复用引起的过度设计呢？ |
正在阅读：关于软件复用的思考关于软件复用的思考
2004-04-01 11:05
出处：CSDN
责任编辑：sdq
键盘也能翻页，试试“← →”键
