UML、面向对象与契约式设计

UML、面向对象与契约式设计

创建人： appleleaf 　　UML与面向对象编程 　　如果是想认真学UML，机械工业出版社的三本书《UML参考手册》、《 UML用户指南 》和《 UML和模式应用面向对象分析与设计导论 》就足够了。《 UML和模式应用面向对象分析与设计导论 》这本书，其实应该叫《UML实例分析》比较合适，很适合面向对象和UML的初学者练手用 　　是Craig Larman的Applying UML and Patterns使我对UML第一次有了亲切感，也在一定程度上认可了UML的价值。不过我现在还没有开始运用它，所以不想、也没这个能力就这个问题多说什么。 　　我的UML知识是用了一周从Rational的CD tutorial中学到的（可在Rational Suite的CD2中找到），另外就是我问Rational要到的Inside UML的CD-ROM。通过那些图文并茂的tutorial，我觉得学习的效果还是不错的。 　　对于OO，我曾经从china-pub上面拍卖到一本小书，叫Object Technology：A Manager's Guide，觉得里面的叙述算是比较清楚的。薄薄的一本书（含index两百多页），内容涵盖了对象技术的基本思想、对象技术的重要概念、面向对象数据库、对象技术在企业中的实施等等方面。作为帮助初学者的入门手册、开发者的速查手册都不错。如果有机会，希望国内的出版社可以考虑引进该书。 　　我非常同意孟岩的说法。这让我想起维特根斯坦在《逻辑哲学论》里举的一个例子：我们可以在几何图象中描绘出不符合空间规律的情景，但无法在空间图象中描绘不符合空间规律的情景。或者换句话说：UML能画的，OO语言未必能实现，实现了也未必就很好。因为UML和C++、Java，毕竟是完全不同的语言 　　我对OOSC（Object-Oriented Software Construction, 2nd Edition，清华大学出版社1999年影印版）一直都赞美有加，不是因为它在OO书籍中的Bible地位（说实话，它太厚了，以至于我每次都没有信心把它看完——事实上我也没有看完它），而是它第一章就讲了Software Quality，让我对于程序的本质有了更多的了解。 　　我认为Bertrand Meyer以及他所代表的Eiffel流派对对象技术理解是最深刻的。十几年来，他们在整个OO技术界一直处于支流，这不能不说是一件令人遗憾的事情。我认为，如果Eiffel及其所倡导的Design By Contract理念一开始就被人重视，那么整个90年代软件工程的发展格局可能都会不一样。另外，从语言本身来说，Eiffel也是非常出色的，我觉得无论将来想不想用这种语言开发项目，认真的学习一次是大有意义的。 OOSC我正在看，里面有不少令人耳目一新的观点，初读起来觉得诧异，细细想来却觉得本该如此。比如把command和query区别对待的观点，所谓访问形式一致性原则(Unified Access Principle)，等等，都令人有拨云见日的感觉。 　　Eiffel的立足点是可扩展性、可复用性和可靠性。我记得前不久我们在一起讨论，这几个目标正是令我们困扰的东西。真的能编写可复用的组件吗？测试难道是保证软件质量的唯一手段吗？是不是面向对象发展到今天，都一直达不到这几个目标，最后只能给所谓的“面向组件”技术当垫脚石呢？读了OOSC，很多疑惑豁然开朗，信心又回来了。 　　契约式设计 　　《 Design by Contract原则与实践 》 　　第一次看到Design by Contract，是在网上的一篇文章，觉不出有多大的价值；第二次看是在OOSC，觉得的确有价值，对于解决所谓“软件危机”大有帮助。我刚翻译的《 最后期限 》里面就有一句比较经典的话：软件模块很不容易出错，即使出错也会被程序员发现；软件的错误总是在模块与模块之间的交流上。而Design by Contract很大地帮助了程序员之间、模块之间的交流。 　　按照裘教授那本书的理论，程序设计是一个规范逐步精化的过程。你首先必须确定一个规范是可行的，然后确定对这个规范的精化的过程是可行的，这样才能得到合法的程序。而在我们使用的OO语言（例如C++、Java）中，并没有证明一个规范是否合法，换句话说，我们并没有保证client以合法的方式来调用我们的模块、使用我们的返回值。我们只把这些要求写在文档里，天知道client会不会按照文档来做？恶魔前几天问我“如何证明面向对象的科学性”，我想他的迷惑也有这个原因。 　　差不多是这个意思。我看到的每本软件工程的书，都试图解答这个问题，有的说是因为软件太容易抽象了，有的说是人们对软件重要性的重视不够，各种观点都有。但是我认为，那些都是次要的，最重要的原因是，自顶向下的软件设计方法真正蕴藏的是一种集权的思想。 　　按面向对象的行话来说，在结构化程序中有那么一个god object，掌控一切，从你这个模块的生死大权，到你的生存行为模式，你的内部组织形式，这个god object无不了如指掌，它统揽一切，随时可以以至高无上的身份干涉各个模块的行为。也正因为如此，它承担了沉重的职责。