整理和抽丝剥茧---看家本领

李维的borland传奇

第十三章    软件科技的发展和Borland的未来

 

不都是整理和抽丝剥茧吗？

我在从事信息工作的生涯中使用过数种不同的程序语言、数据库、组件模型以及
Framework。面对许多新的技术不断地出现，开发人员似乎陷入了永远学不完新东西的
梦魇。不过，如果开发人员仔细回味许多技术的本质，却会发现这些技术其实只是把
我们已经了解的东西再以更细致化的方式加以运用，关键在于开发人员是否注意到了
这些本质和趋势而已。

例如，目前在C++中流行得火热的Template、Policy-Based template，在Java、Object
Pascal和C#中当红的接口程序设计，以及各种组件模型和Web Service中的服务接口
等，如果我们仔细地咀嚼，会发现许多的东西正是发挥程序员原本就拥有的整理和抽
丝剥茧精神，再加以发挥的东西。这怎么说呢？让我们以数个例子来说明读者就容易
了解了。

首先让我们想想为什么会出现数据库这类的产品？很简单，因为由于数据愈来愈多，
数据种类也愈来愈繁杂，因此造成了我们需要一种软件产品能够整理这些数据让它们
更容易的被我们处理和使用，因此才有了数据库的想法和产品。

在每一个程序员学习撰写程序代码时，也会发现随着撰写的程序代码愈来愈多，许多
的程序代码不断重复出现和被使用，因此很自然的程序员开始使用例程(routine)/子
程序(subroutine)或是过程(procedure)、函数(function)等机制帮助我们进行程序
代码整理和抽丝剥茧的工作。

这些数据和程序代码整理的工作几乎是每一个程序员的求生本能，只是有的程序员只
做基本的整理工作，而更聪明的开发人员则对于整理的工作有不同的看法，进而促使
了许多延伸软件技术的出现，也开始对软件开发产生了重大的影响。例如，对于原本
杂乱的程序代码以数据和程序代码分离的看法而逐渐产生了面向对象的技术，以分离
例程/子程序和数据类型为看法的应用则产生了类似C/C++中的template技术，而以函
数面对服务的看法，认为开发人员应该面向服务的开发模式则造成了接口程序设计
(Interface Programming)的应用热潮。虽然现在这些从程序代码延伸出的技术都独领
风骚，在软件开发界中产生了重大的影响和开发模式的改变，但是，如果我们追根究
底来观察，这些技术不都是从对程序代码和数据的分析、整理和抽丝剥茧之后，以更
精致的方式来处理和开发软件吗？

因此，本着相同的想法和精神，聪明的开发人员开始脱离单一程序语言的架构而进入
了开发出可重复使用的软件组件模型，让不同的程序语言都能够在统一的组件模型中
达成团队开发的功效。这个更聪明的整理和抽丝剥茧的想法造就了CORBA、COM/COM+
和EJB等组件模型的驱动力。

除了脱离程序语言之外思考的开发人员外，另外有一些开发人员则再次回头检视本身
和他人的程序代码，并且努力搜寻优良和成功程序代码的基因，因此发现了这些优良
和成功的程序代码似乎都有着类似的模式和架构，再经过进一步的分析之后终于产生
了Design Pattern，这成为目前最重要的软件开发模式和技巧之一。在这之后，这些
聪明的开发人员了解到如果能够成功运用Design Pattern，并且把程序设计转变成以
服务为目标的方式，将更能够简化、标准化和结合Design Pattern的运用，并且隐藏
复杂的实现技巧，这就进而产生了Service Interface Programming的观念和技巧。
由此可见，只要开发人员能够发挥细心整理和抽丝剥茧的能力，那么即使无法创造出
伟大的新软件工程或是软件技术，但是仍然能够帮助我们增加生产力和软件品质。因
此，对于开发人员来说重要的不是无止境地学习层出不穷的各种新技术，而是到底有
没有了解这些技术之后代表的观念、思想，以及学习最重要的对于软件开发整理和抽
丝剥茧的能力。在我的工作生涯中，一直认为技术终究是会被大多数的人学会的，但
是在辛辛苦苦地努力这么多年后，到底我们的思想、眼光和抽丝剥茧的能力是否有所
精进呢？如果没有，那么我们永远就像被蒙着眼睛，只能尾随着他人告诉的技术前进，
永远找不到自己的方向。

现在，再让我们以一个C++的例子来证明只要开发人员能够看透程序语言和技术背后
代表的真实意义，那么即使是在已经被众人熟知的技术中，仍然能够创造出新的技术
和含义。在Andrei Alexandrescu先生所著的"Modem C++Design"一书中，我们再次看
到了聪明的开发人员对于程序语言的了解和对于程序代码撰写整理以及抽丝剥茧的惊
人能力。Andrei的想法不算复杂，但是却巧妙地运用了对于C++ template深刻的了解
而创造出了自己的精彩之作。其实，全书呈现的思维之妙，让读者可以从一开始的小
范例就看出如何运用已经广为人知的技巧之后呈现出的不同风貌。

例如，Andrei想法是以Policy-Based想法为主，以各种不同的准则来提供服务函数，
那么通过C++ template的能力，让开发人员能够根据自己的需求来选择需要的Policy
和数据类型，结合于C++的template，可以捉供开发人员前所未有的自由度，并且开
启了以往函数库开发人员无法想象的挥洒空间。例如，下面的程序代码中提供了三个
不同的类别，这三个类别都可以建立指定类别T的对象实例(Object Instance)，但是，
这三个类别各自使用了不同的方式来建立T的对象实例。在这里提供了建立T类别的对
象实例的准则Create()方法，但是却允许开发人员自由地根据自己的需求选择要使用
那一种方式来建立对象实例。

由于上面的三个类别提供了相同的Policy(其实，从Service Programming的角度来看，
可以说它们都提供了相同的服务)，因此，开发人员可以再自行定义一个consumer类别，
并且结合C++的template功能，让这三个服务类别成为客制化数据类型，再通过template
的能力，自由地被开发人员选择使用。例如在下面的程序代码中，WidgetManager
类别通过template功能可以在编译时期动态决定使用那一个Policy类别作为父代类别，
而自动拥有建立T类别的对象实例的能力。

最后，我们可以再次使用template能力在编译时期由开发人员代入欲建立的T类别的
实体类别定义，通过template功能结合Policy服务和各种不同的数据类型。例如，下
面的程序代码即指定了使用OpNewCreator这个Policy服务类别，以传统的new操作数
来建立Widget类别的对象实例，并且定义成新的客制化类型MywidgetMgr：

typedef WidgetManager<OpNewCreator<Widget>>MywidgetMgr;

在这个范例中，我们看到了Andrei真正了解了程序语言的机制，并且经过他的思考和
抽丝剥茧之后，开创出了以Policy为主的template class library。Andrei的这番思
考的确为C++语言开创了新的应用和视野，这正是发挥开发人员聪颖的整理和抽丝剥
茧能力的另外一个好典范。

不过，C++的template功能却只局限于C++程序语言本身，这是因为template是C++语
言本身的特性，只有C++编译器提供了强劲支持。所以，C++的template无法在程序语
言之外和其他的程序语言合作提供类似组件模型的能力，因为其他的程序语言并不了
解template，也不支持template，这也是为什么Microsoft会以COM来提供不同程序语
言之间的整合，EJB则更单纯地只限定使用Java的原因。

其实在上面讨论的C++ template中，仍然可以通过混合编译时期和执行时期的功能来
提供C++在组件模型和其他程序语言或是技术结合的能力，同时又能够使用C++本身强
劲的语言机制。例如，我们可以在外部使用XML作为组态文件，以指定我们想要使用
的Creator以及想要建立的对象。例如下面的XML内容即指明了和前面相同的Creator：
OpNewCreator，以及要建立的对象：Widget：

而C++可输出一个纯粹的服务接口，类似COM的接口以便和其他组件模型或是程序语言
整合：

最后，在CPPCreator的实体衍生类别中可以通过分析XML组态文件的内容来决定建立
何种的Manager：

上述的机制可以让C/C++语言提升至组件模型和其他的技术整合的层面，又能够仍然
使用本身强大的template、Policy-Based template或是template函数库。当然，这
里我并不是以讨论C/C++程序语言的技巧为主，不过，上面的程序代码仍然可以进一
步使用dynamic dispatch来改善，成为品质更好的程序代码。

其实，这些想法和实现机制仍然是在使用整理和抽丝剥茧程序代码的方式来解决问题，
只是以更细致的想法重新给予程序语言或是工具新的意义并且运用在日常的开发生活
之中，有时候只要脑筋稍为转个弯就能够看到新的应用。

现在，除了在程序语言层面运用各种整理和抽丝剥茧的技术来增进我们开发的速度和
品质之外，许多人已经开始运用相同的想法在建立企业应用系统了。例如，现在许多
人已经了解Design Pattern除了在程序语言方面有实质的帮助之外，在企业应用系统
的设计方面更有极大的应用价值。而且许多人已经开始整合这方面的Design Pattern，
例如Martin Fowler最新著的"Patterns Of Enterprise Application Architecture
"一书中便分析和整理了他观察和使用Design Pattern在设计和发展企业应用系统的
心得。在这本书中，Martin Fowler也清楚地说明了他只是发挥了整理和抽丝剥茧的
原则提供给开发企业应用系统的开发人员参考，许多的Design Pattern并不是他发明
的。可见，现在许多的开发人员只是更精炼地观察和整理多年的开发经验，以萃取出
更佳的Coding和开发的技巧以及开发惯例。

而Design Pattern运用在企业应用系统中的功用是能够帮助开发人员更了解整个系统
的架构，并且更容易掌握如何分门别类企业应用系统不同层次之间如何的切割和分发，
能够营造出体质更为健全的复杂企业应用系统。

目前，这股重新整理和抽丝剥茧的风气也已经蔓延到各种信息开发领域，从程序语言、
组件模型一直到大型应用系统的设计和开发。我认为，下一步将继续进入整个开发流
程的领域之中。当软件厂商提供了完整的开发流程工具之后，就开始会有人研究如何
在开发流程中再度应用Design Pattern等技术。

因此在未来，开发人员必须了解Patterns，并且在开发的过程中时时注意软件开发的
趋势和使用惯例，不断吸收更多的技巧，以更精致的思想和方式来开发软件，如此一
来才能够脱颖而出，在软件开发的生涯中出人头地。


Web Service Works

SOAP和Web Service从去年开始快速兴起，并开始占据信息整合应用的市场。虽然许
多人提出对于SOAP和Web Service执行效率和安全性的质疑，但是，SOAP和Web Service
的穿透力、整合力却无庸置疑是极具吸引力的。因此，目前Web Service的各种规格
除了蓬勃发展之外，Web Service的应用也的确开始出现在我们的四周。不过，Web
Service到底应用在哪些方面呢？SOAP和Web Service目前在信息业界使用的情形如何？
相信这些都是许多人关心的问题，也是许多人想要知道的答案。

最近，我被邀请到一家信息机构交流信息技术的心得。主持人告诉我他们现在拥有一
个分布区域极为广大的信息系统。每一个区域使用的硬件、操作系统、数据库和开发
工具都不同。而且，目前这些系统之间并没有专线连接在一起。现在他们想要整合这
些系统，而且希望能够在机构中心向不同的区域查询货物数据并且在机构中心整合查
询到的信息。

这位主持人询问我有没有什么方法可以完成这个信息架构。在详细地讨论之后，我了
解到机构中心从各个区域查询的信息都是属于小量数据的查询。由于在每一个不同的
区域都有自己的数据库，因此可以通过每一个区域的数据库服务器从大量的数据中撷
取查询数据，再把查询到的结果传回机构中心进行简单的整合工作。

对于这个信息架构，我想最简单的方法就是在每一个区域的服务器上实现一个CORBA
服务器，再由CORBA服务器对外提供查询接口。由于CORBA拥有跨平台、数据库和开发
语言中立的特点，因此非常适合使用来作为原有专属系统提供对外的标准服务接口。
有了CORBA服务器作为服务接口之后，我们可以继续把CORBA服务转换为标准的Web
Service，再由机构中心使用SOAP，即可轻易地使用标准机制穿透并且整合原本的异
质系统。

使用Web Service的原因是由于在这个应用中只会有少量的资料查询，因此Web Service
绝对可以胜任，而Web Service提供的穿透力和整合力是其他技术难以相比的。对于
安全的需求，可以使用HTTPS加上CORBA的安全服务即可提供一定的安全可靠性。

原本看起来困难的事情一下子就被Web Service和CORBA联手解决了。这正是一个非常
好的Web Service应用范例。

那么在2002年，Web Service在信息业界应用的情形到底是如何呢？到底有没有信息
系统在使用SOAP和Web Service技术呢？其实，我们从各种开发工具都支持Web Service
的应用来看，一定是有人已经在使用Web Service了，否则没有必要几乎所有的开发
工具都争先恐后地加入对于SOAP和Web Service的支持。

下图是2002年信息界对于使用Web Service的最后调查结果，从数字中我们可以看到，
没有使用Web Service的比率是43.2％，但是超过50％的调查显示Web Service已经
或多或少的被应用在信息系统之中了。而这些统计数据也代表了Web Service被实际
应用的证明。

另外一份对于Web Service应用的调查结果如下页所显示。我们可以看到在2003年中
Web Service将有更大的使用比率，可见Web Service的应用将会快速地提升。

如果我们把两份统计结果以趋势图同时呈现的话，会发现Web Service应用的成长比
率几乎不会输给一般的开发工具或是程序语言的成长比率。

在2003年Web Service除了将愈来愈普及之外，新的Web Service规格也将慢慢完善并
且开始被软件厂商实现。除此之外，也开始有信息厂商对Web Service的缺点加以改
善推出变形的解决方案。不过千变万变，不变的是在现在信息多元化的时代正显示了
我们的确需要Web Service代表的穿透力和整合力。

许多人当初说Web Service是不实际的技术，从目前的各种迹象和统计数字来看这些
人似乎是错了。Web Service的简单化不代表无用，其缓慢也不代表不可用。我们只
需要在适当的地方使用适当的技术，Web Service就是一个很好的例子。毕竟当初Don
Box在定义SOAP时最原始的想法本就是"简单(Simple)"，不是吗？