基于domain object进行OOAD设计

OO编程的技术是一门代理的艺术。职责划分明确，把接口定义好，把实现交给另外的类来做。著名的Proxy, Delegate模式就是这样。
首先把变化的部分和不变的部分 划分出来。不变的部分，就成了框架。变化的部分，就是程序员自己做。
可是我自己不想做，我希望框架帮我把变化的部分也做好。怎么办呢？
这就要用到代理的艺术。把要做的事情定义好，然后把具体的工作交给别人做，这样自己就不用作了。这种方式是最灵活的。

这篇文章其实无意中点了OOAD的一个死穴。
笔者转向Java Web编程前从事的是传统的Delphi C/S编程。转过来后就觉得J2EE分层太多，每到更改，每层几乎都要涉及，相当麻烦且易出错。在Java Web之余，又涉及了一些ASP、PHP之类的东西，才发觉Web编程也可如此简单，不禁对J2EE产生了很大的疑问：本来可以简单实现的东西，何必搞得那么复杂？
近两年OO水平上涨后才逐渐领会到其中玄机。OO与分层就重要的好处其实业务逻辑的复用！OOAD将数据存储、业务逻辑、表示层分离，就可以适应多种数据存储方式与表示层技术的变化。比方说，你就可以选用多种数据库、XML甚至文本！也可以选择WEB、Rich Client以至于手机、PDA。当存储层与表示层变化时，业务层几乎可以保持不变。原因其实也简单：传统的过程式编程是把他们在一块写，而OO则是分开来写。而天下事总是利弊相当，OOAD的高适应性也就必然为其带来高度的复杂与费时，甚至修改时的麻烦。综上所述，OOP其实是便于扩展而不适于修改。原因简单之极，写在一起的改起来只需改一处，分开写的改起来则要改每一处。
所以是否采用OOAD，要因软件产品的定位而论。如果考虑的是扩展性，业务逻辑相对固定，而存储层、表示层变化多的情况下，OOAD当是不二之选；而存储层、表示层相对固定，业务逻辑变化大的情况下，则应选用过程式编程。如果二者变化程度均衡，则可采用MS骑墙式的方法。笔者这番大胆言论其实并非由理论推导而来，而缘于对当今软件界的实际观察。真正的企业级开发无疑J2EE是主导，这符合第一种情况；而变化迅速的互联网界则以PHP为王，小型桌面系统至今仍以VB、PB、Delphi为佳；而中型系统，无疑以.NET发展得最好。