展望后OO时代

 在IT业的领域内，预测未来的技术发展是非常困难的，尤其是短期的预测就更显尴尬：如果要做一个长期的预测，我可以放心地谈论“摩尔定律失灵”、“量子计算投入应用”、“生物芯片和虚拟现实技术全面发展”、“传统密码学全面崩溃”之类的大话题；但是，如果像这样对未来一年中的IT技术做一个预测，恐怕有一半要成为明年年底时的谈资笑料。所以，我决定展望一些最可能对中国软件开发人员造成影响的技术。这些技术多半已经不是新东西，其中一部分已经引起了广泛的关注，只是尚未在实际应用中体现出足够的价值，所以这样的预测会比较保险（同时也比较实用）。

  如果把过去的十年称为“OO时代”，相信不会引起太多的异议。到目前为止，面向对象（Object-Oriented，OO）技术得到了最为广泛的应用，并且也被证明不是软件开发的“银弹”。从Robert Martin到Bertrand Meyer，研究者们把OO的能力和局限摸了个一清二楚。同时，人们也在传统的OO三要件（封装、抽象、继承）基础上发展出了更多的新技术，借以弥补OO的缺陷，使OO能够更好地解决软件开发中的问题。这些“建立在OO基础上、并对OO作出扩展的新技术”被广泛应用的时期，我把它称为“后OO时代”——这是一个即将到来的时代。

  在我看来，“后OO时代”应该由三个部分组成：对OO进行扩展的编程技术、更加实用的方法学、覆盖软件生命周期各阶段的集成开发环境。下面，我将分别介绍这三个部分。
 
  新编程技术：柳暗花明
 
  OO技术的一大局限性就是：它对软件职责的划分是“垂直”的。在一个标准的对象继承体系中，每一株继承树负责软件系统中一个特定部分的功能，对象的行为是在编译期决定的。但是，在实际问题中，常常有一些“水平”的功能需求，例如：一个容器（container）对象应该可以容纳各种各样的对象；一个日志（logger）对象应该可以记录所有对象的行为。这些“水平”的功能需求有一个共同的特点：它们的操作对象横跨了多株继承树，并且操作本身对于操作对象是透明的。这就向软件开发者提出了“功能正交分解”的要求。在标准OO技术的环境下，人们想出了一些解决方案（例如单根继承体系和某些结构型设计模式），但结果都不能令人满意。

  OO技术的另一个大问题是接口定义。在传统OO环境下，对象的开发者没有任何办法确保使用者按照自己的要求来使用接口。他唯一能做的就是：在接口之外提供一份详细的文档，说明接口的使用要求。当然，文档可能疏于维护而与事实不符，使用者也可能根本不看文档，因此这个问题也并没有得到很好的解决。

  如果你也遇到过上面这两类问题，如果你还没有找到解决的办法，那么请注意下列的几个术语。它们可能将很快进入你的生活，成为你需要学习的技术。

  Aspect-Oriented Programming（AOP，面向方面的程序设计）。《程序员》杂志在2002年第11期介绍过AOP的概况，这是一种对代码进行再分析、再处理而解决横切关注点问题的技术。在2003年中，除了AspectJ之外，我们应该能看到适用于.NET的AOP工具出现，甚至可能有适用于Delphi和C++的版本。另一方面，AspectJ可能由“处理源代码”转为“处理字节码”，从而具有更高的实用价值。

  Generative Programming（生成式程序设计）。C++的创始人Bjarne Stroustrup曾经说过：“我以为，自从OOP问世以来，可称为‘根本性’的新型程序设计技术，惟有泛型程序设计（generic programming）和生成式程序设计  （generative programming）技术。”generative programming这种诞生于数值计算领域的技术，很可能在一般程序设计领域中找到更多的用武之地。

  Design by Contract（DbC，按契约设计）。2002年，中国的程序员听到李维先生带来的一个词：CBD（基于组件的设计）。一时间，“组件”被炒得炙手可热，似乎就快成为软件业的银弹了。不过，如果没有Design by Contract（或者类似的技术），“基于组件的软件工程”还将继续扮演水中月镜中花的角色——实际上，在没有Design by Contract的时候，我们居然还做了那么多的面向对象程序，这才真是件奇怪的事情。到2003年，你还要让DbC从你的视野中溜开吗？
 
  敏捷方法学：方兴未艾
 
  2002年，随着人民邮电出版社的“极限编程（XP）丛书”问世，中国的软件开发者们第一次全面、系统地了解了一种敏捷方法学（agile methodology）。敏捷方法学给人们带来了巨大的心理冲击，那种张扬个性的主张是任何一个软件开发者都无法抵抗的诱惑。就连Rational的首席科学家Ivar Jacobson也曾在接受本刊记者采访时声称“RUP与XP一脉相承，XP是RUP的轻量级版本”。当为数不少的中小软件企业尝试了重量级的RUP（并吃到了苦头）之后，可以预见，敏捷方法学将在更多的地方发挥作用。
继XP的深入人心之后，在2003年，以下的一些与敏捷方法相关的“关键词”可能会广泛地进入中国软件开发者的日常工作：

  Agile Modeling（AM，敏捷建模）。由Scott Ambler所提出的“敏捷建模”是一组软件建模阶段的指导性原则。对敏捷建模最好的使用方法，就是将它结合在一种完整的敏捷方法学（例如XP）基础上。当XP真正大规模地投入到企业开发实践中之后，敏捷建模会自然地受到XPer们的关注。
  Refactoring（重构）。
  Unit Test（单元测试）。
  Daily Build（日创建）。

  对于这三个词，我不想再废话。如果你有兴趣了解它们的含义，可以去看Kent Beck的《解析极限编程》（eXtreme Programming Explained）或者Martin Fowler的《系统重构》（Refactoring）。但是，对于那些迫不及待地想要一试身手的读者，我要提醒你：在没有顺手的工具之前，不要在项目中尝试这些做法。如果想要重构、想要单元测试，先装好xUnit；想要日创建，先装好Ant和CVS。而最好的选择是：先购买一个足够方便又足够强大的IDE。
 
  集成开发环境：三足鼎立
 
  “工欲善其事，必先利其器”。对于成熟、高效的软件企业来说，功能齐备且方便易用的集成开发环境（Integrated Development Environment，IDE）是至关重要的。在2002年底，Borland收购Together、IBM收购Rational之后，Borland、IBM和微软三大巨头的IDE都拥有了需求分析、建模等软件工程特性，从而真正覆盖了整个软件开发生命周期。如果“微软收购Borland”的流言没有不幸而成真的话，2003年的IDE市场就将由微软、IBM和Borland鼎足三分，而软件企业的选择也将更加简单明了：

  微软阵营：尽管微软的技术从来都不是最先进的，但微软的工具从来都是最出色的。强大、易用、人性化，是Visual Studio一贯的风格。在2003年中，我们将看到.NET 2.0的发布。.NET的成熟和Web Service的完善，将使Visual Studio .NET成为IDE中的“天王山”。不过，我仍然认为Visual Studio .NET只能是Windows平台上的NO. 1——虽然微软说.NET将“完全跨平台”，不过我更乐于把这看成微软的“业余爱好”。

  IBM阵营：在过去的一段时间中，IBM一边暗示着微软有垄断行为，一边又生产出一些极其难用的软件把潜在用户都吓跑。不过，从WebSphere  Studio Application Developer（WSAD）开始，IBM似乎也意识到了一个易用的IDE对于开发者的重要性。更令人开心的是，在2003年中，WebSphere Studio将变成一个强大无比的Java开发工具，成为大型、超大型Java应用开发的不二之选——一个差强人意的Java IDE加上DB2加上WebSphere，再加上ROSE、XDE和RUP，再加上蓝色巨人的品牌和服务，你知道这意味着什么吗？

  Borland阵营：在开发者的心中，Borland就代表着最好最纯粹的技术。在2003年，不论你选择C++还是Java、.NET还是Linux，Borland都将为你提供一个好用而且熟悉的开发环境。而且，比起Visio和ROSE那“可怜”的建模能力来，Together对UML的运用简直是出神入化：你不但可以完全无缝地在代码和模型之间切换，还可以直接生成一些设计模式的程序框架，还可以对代码进行自动重构，甚至还可以从代码导出顺序图！假如Borland能把Together的这些功能全都移植给Delphi和Kylix的话……世界将多么美丽。

  如今的IDE都具有了建模、代码生成、编辑、编译、集成、运行、调试、发布等“全系列”的功能。不过，在我看来，它们还缺少一项重要的特性：真正的在线帮助。我所说的“在线帮助”，不是指像MSDN这样的“关键词索引”，而是从网络上即时下载数据、即时解决疑难的能力。最近Google加上了“新闻搜索”的功能，据说还将推出“购物搜索”的功能，但愿Google的成功能给IDE开发商带来一些灵感。
 
  结语：新年快乐
 
  在2002年，我非常高兴地看到：《程序员》在2001年第10期所介绍的泛型程序设计受到了众多C++程序员的关注，在2001年第11期所介绍的中间件概念已经实实在在地养活了为数不少的软件公司。对于一本技术刊物来说，没有比看到自己引荐的技术受到重视更欣慰的了。在2003年中，《程序员》将继续关注业界最新甚至是最超前的技术。如果你仍然喜欢站在技术的潮头，让我们继续结伴前行。