模板，软件开发中的应用

模板，软件开发中的应用

 

 

自六十年代中期到七十年代人们感觉到“软件危机”以来，软件工程也已经经理了整整35个年头了；然而，手工作仿式的软件开发形式在这儿依旧那么严重，而更让不解的是，每个人工作已经相当一段时间了，竟然没有去尝试着寻求新的解决方法（已经被别人用过很多次的方法）；结合于实际情况谈一谈自己几年来的软件开发经验，以便于和更多的同道中人交流；应该具备的前提条件：

l          模板的概念；

l          重构的方法；

l          OOP思想何以出现如部门经理以及开方人员的困惑？

为什么会让一个开发人员感觉到厌倦？其实问题就在于一惯的惰性开发方式(Copy-Paster)占据着他们的头脑，而没有想着借鉴别人的或自己尝试着利用更好的方式去解决自己面临的困惑；软件开发的本质就是制造软件，然而和其它的制造业不同的是软件开发里的评测标准是一个相当抽象的过程，然而，在开发过程中，有很多的模式是相同的或是有共性可找的；纵然不能说每个软件按照某个特定的开发模式去做，但是找到了这些共性，我们同样可以达到代码的重复利用，再加之代码的一次次重构，如何做到这两点？可以从下边的情况进行分析：

一个优秀的开发人员会在工作中总结出很多开发经验；而将这些开发经验用了进行一定的分析，完全可以利用模板将其来实现代码的重复利用，而不需要进行每个软件开发过程中都进行Copy-Paster甚至重新手写代码；特别是在多人合作的项目中，当项目经理进行了概要设计、详细设计之后，对其成员进行了各尽其责(此处并非是在排斥敏捷开发方法)，但是需要做到这一点着要要进行接口设计，即使按照螺旋式、级端开发模式也同样需要定义各个模块的接口，而接口混乱将会的结果将导至软件合并的灾难，此时就根本也无法再提到“测试先行”；而大的方向如此，我们将问题范围缩小到具体的某个功能模块中，其实，一个小的功能模块也如一个软件一样，里边包含了方方面面；同样，以面向对象的方式来分析，即使一个很小的模块也可以按如下所示的方式进行分析：

功能模块->细分为各个对象->对象于对象之间的接口定义->具体到每个对象的开发；

根据如上可以很清楚的看到，我们将一个软件开发过程化分成了很多个原子(Object,对象)，既然可以划会出各个对象编程，那么模板也便应时而生，模板更新是一些对象集合，对于本程序中来说，它仅仅是一个多功能对象或多功能模块的载体，然而，模板的应用并非仅此，既然做为模板，它就可以为多个应用程序所共享，而从所周知，每个开发工具，或每种OOP语言都支持组件形式的重复利用，那么我们当建立了一个完整的模板之后，就可以进行模板注册！继而进行多个软件的共享，如此便实现了代码的重新利用，而且，它的优点也不仅仅如此，模板，是一个灵活的小型组件，用户(程序员)可以根据自己的需求，定制模板的功能、扩展模板的接口，使模板的OO思想完全的体现到每一个软件之中！那么如何来制定一个模板？这就是我们大家都需要知道的，也许，您已经在您的程序中经常的用到模板，或是已经将模板的概念引入到您的程序中，但是您还尚末进行模板的进一步优化，让我们一起来分析这个过程；模板给我们的程序带来的好处就是：灵活、代码重复利用、业务规则的明确、商业规则的清晰化……从它给我们带来的效率的方面就可以清楚的了解一个模板甚至就是一个Object!或是一个Component!既然程序中出现了很多的代码重复的地方，当我们还没有能力将设计模式晤的很透或是还没有把握将代码重构、业务逻辑、商业规则等充分的进行伪代码的划分或是模型式的机制还尚末成熟的情况下，很难做到代码的再生应用，但是至少我们已经可以感觉的到，代码有很多重复的地方让我们厌倦，甚至在一个软件中、或是一个单元体中就有很多重复的代码，可我们又不能借用Data Option Public Unit 来进行统一归划时(我并不提倡用Data Option Public Unit进行重复代码的集中处理)，我们其实完全可以做到将经常性的、容易发生的重复代码进行整理，至少在头脑中有一个清晰的概念！特别是数据库繁杂的操作；然而，回过头看一看我们曾经写的代码，不但凌乱不堪，没有什么逻辑可寻，也许还会发现程序中，到处可见的Copy – Paster的痕迹，那么我们是否应该安静下来整理一下这些凌乱的代码？理顺各个逻辑上的规则呢？势在必行！否则将会产生新的“软件危机”；当我们整理清楚了我们那些凌乱的代码，理顺了各个逻辑规则，并进行了代码重构，还应该做些什么呢？是否就到此为止呢？答案是否定的。因为我们不可能只做一个工程，而如何将我们这次辛勤的劳动收获带给下一个软件中呢？毫无疑问就是将我们此次整理的结果“放”进一个“对象”中，用这个“对象”来处理本软件中将相似的规则、问题，以及将这个“对象”扩展到下一个软件之中！而这个对象就是我们所说的模板；它不仅仅是一些代码的集合；它是给我们提供了很多输入、输出接口的对象（Black Box，黑匣子）；此处想说的是，如果一个程序员还末曾理解OOP的话，他是无法构造出这样的一个“对象”的。因为模板就是一个”对象”；不曾理解OO，如何理解模板？又何谈构造模板？

我们已经知道了，模板是一个什么东西，那么我们再来看一下它将会包含或是应该包含什么东西在里边？我们都知道，对象就是一个封装了各种业务、逻辑规则于一体的实现体，而且，它应该为我们提供一些接口，我们只有通过这些接口来改变这个对象的状态，否则，这个对象将是一个“死”的对象，对我们没有多大的意义；由此可见，这个“对象”是一个活的实体；并且是一个很抽象的东西，因为脱离了本软件，它只是一个概念意义上的组件；作为一个规则载体，它就不仅仅是一Public个Code Unit!它并不仅仅是一个Public Code Unit，否则我们完全可以由一个Puplic Unit来完成我们的操作，而不必再去费心的构造一个对象！虽然，它只能称为一个概念意义上的组件，它将无法为我们实现跨平台、语言的操作；可它既然存在，就要为我们实现某种范畴内的统一，在构造模板的同时，我们不能为有这么一个概念而去构造；而应该想到，它将可以应用在别的地方！这就是它存在的意义，所以，这个“对象”将还要包含一些灵活的规则再其间，如何做到灵活的规则实现？很明确，就是为我们提供接口！然而，也同软件一样，太多凌乱的代码、过程、事件将使软件维护的费用大大增加，接口也同样，我们不能凭空的任意增加或修改；既然是接口，一当确定下来，就不要再想着轻易的改变它！(此处和敏捷方法没有任何冲突)；所以，此处的忠告就是：仔细的整理的代码，理顺所要实现的逻辑规则，用技能、经验去构造的模板；

当然，模板也并非是一成不变的，根据快速元形法或是级端开发方法的形式，我们的模板也有可能将会是一个时刻处于变化的“对象”，但是我们改变它也是有规则的，并非是任以的去改，而是如一个    Object Tree的形式去改变它；模板应该包括什么东西，想必说的已经很清楚了，但是，它做为了一个规则载体，就必须要考虑到性能、效率、以及可维护性、可扩展性等，此处希望可以提醒一部分朋友那种：“以为低成本的硬件可以带起整个系统性能的提高”！我们能处理的问题就不要懒惰；如果达到这种目标？提出两个方面：实现代码的合理重构和测试先行！而关于具体的代码重构以及测式先行的方法可以参考很多现存的资料；我们前边已经提到，一个模板可以是一个概念意义上的“组件”，所以，模板记着注册；此篇文章主要是想着将模板引入到你的软件开发的过程中，不，是每一个软件开发过程中；