企业级应用，有什么理由不用OO？

         这里所谓的企业级应用，就是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，领域驱动设计：软件核心复杂性解决之道。

评论

14 楼 sslaowan 2008-04-14  

agate 写道

嗯~已经扯偏题了……
o(∩_∩)o...
反正选择适合项目本身的架构是最符合现实的，OO是好，大大提高了我们看清问题域的可能性，我们也不能排斥非OO的开发模式！这就是我的领悟~

嗯，当我实践了几种主流的方法，并且研究了它们的渊源，发现OO在本文一再声明的项目中是最好的~~

我不排斥，因为没用过就没有发言权，所以每种方法都做过真实的项目~~

13 楼 agate 2008-04-14  

嗯~已经扯偏题了……
o(∩_∩)o...
反正选择适合项目本身的架构是最符合现实的，OO是好，大大提高了我们看清问题域的可能性，我们也不能排斥非OO的开发模式！这就是我的领悟~

12 楼 sslaowan 2008-04-13  

agate 写道

sslaowan 写道

agate 写道

我觉得不必过于叫真，OO的确是一个十分好的设计方式，企业级应用中似乎国外的很多开发公司都注意到了过去不断叫嚣OO是无意义的，因为企业中最大量的还是数据，处理这样大量的数据很大程度上使用一个稳定的、成熟的数据结构式的编程还是十分理想的开发方式。

在开发过程中过早奢望定义一个稳定的数据结构几乎是不可能的
我说了，数据结构的确定依赖于对问题域的理解，除非是小项目，或者是重编某个系统
否则这种假设是危险的

OO不是不重视数据，而是不只重视数据，而且完整数据结构并非必须，考虑核心数据，问题域核心才是关键的

呵呵，只是探讨探讨，个人是OO支持者。但是在开发的过程中觉得我们开发的程序并不是你所谓的OO。
我们用的是Java这样的OO语言；使用着Hibernate，Spring这样的框架；写着DAO这样的接口；我觉得这是各大公司的普遍现象，这是OO吗？我觉得不是……但是这种开发方式很好，充分利用了Java的OO特性，但是不是OO，是一种建立在数据基础上的开发方式。

这样做可能是OO，也可能不是。
就像很多人宣扬RoR的简单批评J2EE的“无限分层”，我觉得就是对于方法学要活用的无视。但是那些大牛何尝不都是看过《企业应用架构模式》一类书的人，分不分层，分多少层，为何分层他们不是不知道的，那这样说的原因终究在哪呢？
怎样算OO？我在大三做铁道部的项目时，将数据放进VO，将方法放进Bean，自以为是OO，程序的可维护性可扩展性有了很大提高，然而在看了Bob大叔、Larman、Fowler等人的著作后，才逐渐的知道了如何建模。
在我做过的几个项目中，我发现越是大型、复杂、需求模糊、需求变化频繁的项目越适用于OO，越贴近OO设计准则越能有效地完成任务~~~

11 楼 agate 2008-04-12  

sslaowan 写道

agate 写道

我觉得不必过于叫真，OO的确是一个十分好的设计方式，企业级应用中似乎国外的很多开发公司都注意到了过去不断叫嚣OO是无意义的，因为企业中最大量的还是数据，处理这样大量的数据很大程度上使用一个稳定的、成熟的数据结构式的编程还是十分理想的开发方式。

在开发过程中过早奢望定义一个稳定的数据结构几乎是不可能的
我说了，数据结构的确定依赖于对问题域的理解，除非是小项目，或者是重编某个系统
否则这种假设是危险的

OO不是不重视数据，而是不只重视数据，而且完整数据结构并非必须，考虑核心数据，问题域核心才是关键的

呵呵，只是探讨探讨，个人是OO支持者。但是在开发的过程中觉得我们开发的程序并不是你所谓的OO。
我们用的是Java这样的OO语言；使用着Hibernate，Spring这样的框架；写着DAO这样的接口；我觉得这是各大公司的普遍现象，这是OO吗？我觉得不是……但是这种开发方式很好，充分利用了Java的OO特性，但是不是OO，是一种建立在数据基础上的开发方式。

10 楼 sslaowan 2008-04-11  

agate 写道

我觉得不必过于叫真，OO的确是一个十分好的设计方式，企业级应用中似乎国外的很多开发公司都注意到了过去不断叫嚣OO是无意义的，因为企业中最大量的还是数据，处理这样大量的数据很大程度上使用一个稳定的、成熟的数据结构式的编程还是十分理想的开发方式。

在开发过程中过早奢望定义一个稳定的数据结构几乎是不可能的
我说了，数据结构的确定依赖于对问题域的理解，除非是小项目，或者是重编某个系统
否则这种假设是危险的

OO不是不重视数据，而是不只重视数据，而且完整数据结构并非必须，考虑核心数据，问题域核心才是关键的

9 楼 agate 2008-04-11  

我觉得不必过于叫真，OO的确是一个十分好的设计方式，企业级应用中似乎国外的很多开发公司都注意到了过去不断叫嚣OO是无意义的，因为企业中最大量的还是数据，处理这样大量的数据很大程度上使用一个稳定的、成熟的数据结构式的编程还是十分理想的开发方式。

8 楼 sslaowan 2008-04-10  

rtdb 写道

就算是OO无处不在，和企业级应用扯到一起，
就好比举起榔头，到处都是钉子一样。

我说的是：目前来说，企业级应用最好的方法是OO
我没说OO无处不在，数学运算等领域，OO并不适用或最好

7 楼 sslaowan 2008-04-10  

downpour 写道

要看项目的类型。

往往一个项目起来的时候，用户最大的需求是保留当前已有系统的使用习惯，或者要与已有的很多系统进行无缝整合。此时，已经存在了一些很多年前设计的数据库表，以及大量的数据，你要OO，可以啊，先把这些数据迁移过来再谈编程哲学，这时，往往会觉得力不从心。

还有一类项目，完全就是从无到有的，那么尽可能的放开手脚，想怎么玩就怎么玩吧。

其实这些并不矛盾
数据库只是作为持久化的工具而已
跟OO设计并不矛盾，将对象映射为一个并不OO的数据库表也是可以的
我大四做的项目就是为一个遗留系统（一个大型公司的生产业务系统）添加视频监控功能，采用的OO设计，迭代了17版，没什么问题。

6 楼 rtdb 2008-04-10  

就算是OO无处不在，和企业级应用扯到一起，
就好比举起榔头，到处都是钉子一样。

5 楼 downpour 2008-04-10  

要看项目的类型。

往往一个项目起来的时候，用户最大的需求是保留当前已有系统的使用习惯，或者要与已有的很多系统进行无缝整合。此时，已经存在了一些很多年前设计的数据库表，以及大量的数据，你要OO，可以啊，先把这些数据迁移过来再谈编程哲学，这时，往往会觉得力不从心。

还有一类项目，完全就是从无到有的，那么尽可能的放开手脚，想怎么玩就怎么玩吧。

4 楼 Joo 2008-04-10  

ray_linn 写道

OO出来前也有企业级应用..甚至现在80%的企业应用(出自CICS的说明书)还都不是OO, COBOL照样可以支撑一个企业的系统.

OO照样处理不了需求变化的情况,对于需求来说,OO太细小了.

你这个太细小做何解释 不太明白

3 楼 linhong_1001 2008-04-10  

OO可以成就项目，也可以破坏项目，非OO也可以成就项目，同样也可破坏项目，既然如此，OO不是重要的结果才是重要的，OO就像C++，不完美，也不简单。为什么你任务OO对企业应用而言就是最重要的吗，最重要的是什么，是金钱和时间，OO也许不总是对的

2 楼 sslaowan 2008-04-09  

ray_linn 写道

OO出来前也有企业级应用..甚至现在80%的企业应用(出自CICS的说明书)还都不是OO, COBOL照样可以支撑一个企业的系统.

OO照样处理不了需求变化的情况,对于需求来说,OO太细小了.

我只是说对于企业应用而言，与众多方法比较，OO是最好的，那么为什么我们不用OO呢~~

关于应对需求，我只是觉得，OO能更好的随需求变化提供进化式设计的可能。

1 楼 ray_linn 2008-04-09  

OO出来前也有企业级应用..甚至现在80%的企业应用(出自CICS的说明书)还都不是OO, COBOL照样可以支撑一个企业的系统.

OO照样处理不了需求变化的情况,对于需求来说,OO太细小了.