这里所谓的企业级应用,就是Martin Fowler的企业应用架构模式中论述的企业级应用。
在软件工程过去的40年里,虽然没有任何一种方法论能够达到舍我其谁的程度,但是确实在工业界和学术界达成了一些共识:封装,行为优先于数据考虑,依赖于抽象而非具体,迭代开发,领域驱动设计……而OO范型是这些最佳实践的最好集合。
软件的设计,来自对于问题域的抽象,随着对于需求的理解深入,我们的设计会随之演化。结构化范型中首先设计数据库,我认为过早的对问题域进行了数学抽象,往往那些抽象过于远离问题域,它代表了当时对于问题域的理解。而数据库又属于依赖的最低层,这种不牢靠的抽象必然会造成设计的不稳定,因此从本质上讲,这种方法就是不可靠的。而OO可以直接去模拟业务领域,可以尽可能的去贴近实际。因为实际业务运行良好,那么你所设计的模型也会更容易的运行良好。我发现越是贴近现实领域的建模,其进化性越好。
问题领域中不仅包含实体,还包含值对象,服务[Evans03],而数据库建模则往往只强调实体。那么其他有用领域概念就在设计中丢失了。制作大而全的对象是不切实际的,对象属性和行为的确定要来自于业务需求,对象使得添加和减少属性和行为都变得容易。
把一些行为和数据按照主题加以分类,写到不同文件里,就像我们写文章需要划分段落一样,每个段落表达一个意思,如果想补充表达某个意思,就去相应的段落扩展。而类就是这一个个段落。当某个段落表达了不同的意思,就按不同的意思分解。我想这和单一职责原则是有同构性的。那一个个函数就像一个个句子,面向过程设计将这些句子按照应用分布在应用中,而面向对象设计奖这些句子按主题分布在具有业务语义的类中。
企业级应用的特点是:复杂和多变。一个复杂的东西在变是最让人痛苦的。于是尽可能要把它分解为小而简单的东西,让每个变化只局限于一个方面。
某些东西是不容易变化的,比如商业,申请服务,提供/享受服务,结帐,这个大方向是不会变的。商业的一个子集,餐馆,上千年了,基本流程还不是点菜,上菜,买单?菜和帐是千年不变的实体。
无疑,OO比数据库建模向前又走了一步。
做了几个大型系统,和一些需求模糊、变化无常的项目,真找不出什么理由,做企业级应用可以不用OO。
2008年4月10号补充:但是,现实情况却是,很少有项目采用OO范型,人们认为无论什么方法都不可能彻底解决企业应用核心复杂性(即问题域复杂),转而走向干脆不尝试OO。特别是在这个行业混迹多年、并且在学校只学了结构化方法的人。我与几个公司的信息部的人聊天,他们采用的方法都是先设计数据库,然而我用OO为系统添加了一项功能(我们为他们公司开发了系统,然后我去添加新功能),他们对于使用OO表示赞同,觉得是好方法。但是却没有使用。
2008年4月13号补充:需求调研一个阶段告一段落,回到北京准备考试。在火车上一直跟同学讲领域驱动开发,讲我过去做的两个使用OO开发的项目的感受,并对比之前使用面向过程方法做项目的感觉:
1 领域驱动设计,越是复杂、变化灵活的项目越要采用贴近领域的对象模型,只有小的项目才可以尽可能简化对象使得测试刚好通过即可。
2 切忌UI驱动设计。我做的视频监控项目从最初的需求里包含GUI,到后来不要UI,真是惊天动地的大变化。另外一个作业管理的界面我们修改了20多版,而业务还是那点儿业务。UI可以辅助挖掘需求,但是把它作为最后一件事完全可以。
3 切忌数据库驱动设计。关系数据库以数学为基础,距离现实领域太远,过早陷入其中危害无穷。
4 面向对象是比面向数据、面向过程更加先进的方法。我说,当做那个作业管理子系统时,我将函数拆分的非常细,每个函数都是单一职责的,但是管理起来很费劲。我举例说,比如你有一堆帮助文档,包含了J2EE的方方面面,为了方便查找,我想你可能会按照主题将他们放在不同的文件里,然后再放到不同的文件夹里。那么这些文件就是类,文件夹就是包。虽然面向过程编程,你可以采用良好的命名规范,并将其放入单独的文件里(比如Delphi的unit,VB的module),但是其封装性和复用性明显要弱于OO。也就是这种最佳实践再向前迈一步就是OO了。
5 我的感觉是,越是大型、复杂的商业应用越适合采用OO。虽然OO不完美,OO不是银弹,OO也没有REST、SSOA等时髦,也许话题很陈旧,很“入门”,但是,OO在国内应用的现状,就足以反映出,这是个值得探讨的问题。
[Evans03]Eric Evans,2003,领域驱动设计:软件核心复杂性解决之道。