[请教]事务脚本与领域模型的区别
《企业应用构架模式》里第20页讲了一下事务脚本与领域模型的区别，但是本人驽钝，怎么也想不明白。
请大家指点一下。
根据他给出的两个sequence图，就我的理解，事务脚本就是由一个控制器来控制事务的执行，而领域模型则把流程控制分散到一个个领域对象中。
这样有什么好处呢？
问题点数：200、回复次数：65Top
1 楼mis98ZB（Effective Typer）回复于 2004-10-07 11:15:30 得分 0
比如说吃饭这个task：人拿起筷子、端起碗，嚼米饭。
这似乎就是事务脚本了。
那么用领域模型如何分解呢？Top
2 楼mis98ZB（Effective Typer）回复于 2004-10-07 16:14:04 得分 0
自己的理解：
从依赖上来看，事务脚本是趋向于扁平结构的：
A
|
---------+----------
| | | | |
B C D E F
而域对象是趋向于深层树形结构的：
A
|
----+----
| |
B F
|
-----+-----
| |
C E
|
D
对照公司组织结构，以前也是深层树型结构的。
但是由于响应速度以及信息传递失真的问题，现在都改为提倡扁平结构了。
在程序代码中没有信息失真，而且也没有响应速度的问题，所以我们可以尽量地使用深层树型结构。Top
3 楼smallfish2001（为什么这么笨）回复于 2004-10-12 08:32:46 得分 5
事务脚本应该就是我们以前写两层代码时的做法。领域模型是把操作委托给正确的对象！Top
4 楼mig15（米格鸡）回复于 2004-10-14 11:59:15 得分 10
事务脚本：比如要做某件事，就是写个类，这个类知道所有的事（业务规则，数据库，表有哪些字段，字段怎么用），然后该干嘛干嘛，直接该读的读，该写的写--就算解决问题了
领域模型就是照着那大堆OO书说的，搞些类，属性，方法，关系，捣腾好这些，问题也差不多解决了Top
5 楼mis98ZB（Effective Typer）回复于 2004-10-15 09:38:36 得分 0
呵呵，“领域模型”被炒得那么火，说这么简单实在让人有些不敢相信呢！Top
6 楼mig15（米格鸡）回复于 2004-10-15 10:19:44 得分 0
领域模型是一个系统真正体现OO的部分
如果系统比较简单，这部分当然就很小，反而是支持模块，界面模块是大头了Top
7 楼ozzzzzz（希望敏捷）回复于 2004-10-15 10:28:47 得分 50
其实很好解释,利用面向对象的思维组织的关于领域业务流程的模型就是领域模型.
而事务脚本的最明显区别就是任何的一个流程都还是用一个过程的方式进行的.
两者从抽象的角度看脚本的方式,中间的业务层不管你用了多少类,实际上还是一个一个的过程.而领域模型则是一个一个的对象互相合作完成的业务过程.
在一个简单的场景下这样的区别是不明显的,但是在复杂的环境中两者的区别就显著了.特别是我们知道对象的方式更容易被扩展,或者说对象是更容易被增量的.而脚本基本上一旦被确立,更改和修正就麻烦多了.而两者的建造过程也不同,对象的方式是以确立领域中的对象为最初的关注点,脚本则是在关注领域中的过程.比如吃饭这个例子,脚本看到的是吃饭和吃菜这些动作过程,而对象看到的是饭\菜\筷子等等这些对象.而脚本随着扩展基本上就是带来众多的if,而对象随着扩展则是带来更多的方法和对象.Top
8 楼mis98ZB（Effective Typer）回复于 2004-10-15 13:16:28 得分 0
谢谢ozzzzzz老大赐教。
不过我还是有些不明白。
事务脚本的流程，不也可以表达成对象协作么？
如果使用一个控制对象来负责一个/一些流程，那么这样是属于事务脚本呢，还是领域模型呢？
或者两者是度的区别，细粒度多级拆分事务就是领域模型的方式，而长事务则是事务脚本的模式？（就如同我前面所图示的那样）
比如吃饭，
人 ==拿起==〉筷子
人 ==端起==〉碗
人 ==嚼==〉米饭
这算是事务脚本么？Top
9 楼ozzzzzz（希望敏捷）回复于 2004-10-15 14:57:25 得分 0
实际上情况是很简单的,造成目前状况的原因大概还是在于对面向过程的方法不了解.面向过程的一个原则是单进单出,我们看黑客帝国说的有开始有结束就是说的这个.而脚本的方式就可以用这个理解.
脚本的方式其实就是一种由一个动作启动的活动序列,程序就是按照这些序列来组织的.而领域对象则是一种以领域中的概念为基础组织的形式,也就是说对象们组成了一个场景,并且在这个场景中互相作用,从而完成脚本所完成的同样任务.或者说即使没有这些业务流程,你的场景一样存在,这就是领域对象.而如果没有了这些业务流程,你的脚本就不存在了.
实际上这就是一种面向对象和面向过程的最基本区别.很多人也在用类,也在使用模式,但是他们的思维一样是面向过程的,因为他们的世界中除了过程就不存在任何东西了.Top
10 楼zxq520zf（╭⊙_⊙╮)(亿万负翁)(OH,MY GOD!彩票居然中了5块钱!）回复于 2004-10-16 14:32:10 得分 0
学习+顶Top
11 楼jiezhi（风满袖）回复于 2004-10-19 11:44:45 得分 0
ozzzzzz(希望敏捷) 说得真好。Top
12 楼Mybeautiful（天之痕）回复于 2004-10-26 11:41:53 得分 0
ozzzzzz说得太好了..........
茅塞顿开..Top
13 楼Mybeautiful（天之痕）回复于 2004-10-28 07:53:45 得分 5
感觉 领域模型 是否更偏向于分析.
而事务脚本后则偏向于具体实现...
Top
14 楼mis98ZB（Effective Typer）回复于 2004-10-28 11:01:25 得分 0
最近一直加班，经常到2/3点，而且这个问题怎么也想不明白。
大家都明白了，为什么我还是不明白呢？
难道我真是朽木不可雕吗？
@_@
（一）
划分问题域，建立领域模型是不是基于功能（或者说是职能、职责）划分呢？
不是说面向对象要避免陷入功能划分的误区么？
而且MVC这种体系结构，不是明显的功能划分么？莫非使用MVC就违反面向对象的本意了？
（二）
各个域对象都提供了一些职能。那么谁来组织协调这些域对象呢？也就是说谁来组织域对象，谁驱动域对象协作，以完成特定的任务？
控制器？那么这个控制器是不是就是事务脚本的载体呢？
或者说是把逻辑分散到各个域对象中。那么，事务脚本是不是就是指在某一点存在过长的事务处理逻辑呢？
（三）
感觉什么面向对象，什么按自然的事物的方式划分，都只是一个开始而已。
有了一个雏形，在对象协作过于复杂的情况下考虑耦合，在对象只能膨胀的情况下反思内聚，对职责进行分割、重组。
最终得到的较好的做法就形成了模式、体系构架。
这只是一个不断修正、演进的方法，用对象来呈现还是用结构化的模块来体现，都没有本质的关系。
《产生式编程》里所说的“现在面向对象的问题就是它被绑定了太多不是面向对象的东西”，是不是也包括这一点呢？Top
15 楼mis98ZB（Effective Typer）回复于 2004-10-28 11:06:48 得分 0
〉〉或者说即使没有这些业务流程,你的场景一样存在,这就是领域对象.
〉〉而如果没有了这些业务流程,你的脚本就不存在了.
把域对象放到一起才会形成一个场景。
把对象组织起来，让他们协作以形成场景，新的说法是这叫做配置。
然而这种配置，是不是另一种形式的事务脚本呢？
还望ozzzzzz老大多多指教。
m(__)mTop
16 楼flyingbug（Effective Refactoring）回复于 2004-10-28 13:22:47 得分 30
o6z说的：或者说即使没有这些业务流程,你的场景一样存在
这句非常的好～！Top
17 楼mis98ZB（Effective Typer）回复于 2004-10-28 13:27:27 得分 0
-______-
那没有了配置，场景还存在吗？Top
18 楼flyingbug（Effective Refactoring）回复于 2004-10-28 13:46:00 得分 0
to：mis98ZB
关于配置的问题，我是这么想的
假设你的业务逻辑对象对自己的数据和行为都是封装的非常好的
那么针对一个组合业务（如：先检查权限，再实施业务，再写日志）
如果是事务脚本
你需要编写一个业务流程类来定义这个业务流程
当你的系统发布后，如果这个业务流程发生变化
（比如：先检查权限，成功实施业务1，不成功实施业务2，业务1需要日志，业务2不需要日志）
那么这个新的流程对于开发者来说就是一个新的业务（虽然同原来的业务很相似）
你就不得不重新编写一个新的业务流程类来定义这个业务流程
如果是领域对象
我的业务逻辑对象专注与他的领域（包括权限，日志）
而定义业务流程的工作放到配置文件中
业务逻辑对象在配置文件的指导下进行合作（这时候把它们看作是域对象）
如果业务流程发生变化，只需修改配置文件即可
也就是说协作方式发生变化
而包括权限，日志这些通用组件则变成通用的域对象
在配置文件的帮助下跟不同的业务逻辑类合作
而在事务脚本方式下，实际上他们是一个业务逻辑类或事务脚本类的一部分
最后我要说的是
在领域对象中，业务逻辑Bean得以专注与自己的领域问题
如日志，权限等对于他们来说是不同领域的事情
他们无需在自己的代码里关心这些
而在事务脚本中，我们不得不在业务逻辑bean中关注它们（至少关注日志）Top
19 楼flyingbug（Effective Refactoring）回复于 2004-10-28 13:49:36 得分 0
我不知道o6z是如何理解的
我对他这句话的理解是
即使没有了配置，场景依然是存在的
比如说我们去掉配置
就像一个屋子里有很多人，他们在互相聊天，打牌
然后他们忽然都不交流了
但是他们还都在这个屋子里，只是都不动了，这个场景仍然在这里（人在，屋子也在）
然后我们加上新的配置，让他们互殴
这就是新的业务流程Top
20 楼w_rose（w_rose）回复于 2004-10-28 13:51:51 得分 50
如果把A事务作为一个知识点表达和保存起来，并且用于规划（注意这是规划而不仅仅是执行），就需要将A事务自身“数据化”，这需要非常细致（比任何非设计方面的描述手段更细致），这需要先明确和统一概念。描述事务的条件、结果、影响的任何一个规则都需要使用领域对象的符号再加上描述控制逻辑的符号来组成。越趋向数据驱动的系统，控制逻辑越是非常简单，仅区区可数的几条就可以了。Top
21 楼mis98ZB（Effective Typer）回复于 2004-10-28 13:54:13 得分 0
呵呵，我觉得你这个例子里边，既然他们不交流了，那聊天/打牌的场景就不存在了嘛。
也许是我概念中的“场景”有问题？
扯远了，说说我上边的4个问题吧。
先说配置是不是另一种事务脚本怎么样？Top
22 楼mis98ZB（Effective Typer）回复于 2004-10-28 14:00:06 得分 0
谢谢w_rose(w_rose)指点。
但是我有些不明白：
什么是数据驱动？
把事务“数据化”是什么意思？跟配置是一回事吗？
还请多多指教。Top
23 楼w_rose（w_rose）回复于 2004-10-28 14:13:50 得分 0
如果让你去执行（照搬）各个企业管理流程，你只要会执行就行。如果要你去改革它，你就需要首先把过去的思维倒过来，把它们作为研究的对象、将它们自己以及之间的联系用都作为研究对象。
再比如说一个“检查航空发动机故障”的程序，可能每个任务流往往需要持续好几个星期，其流程不可能预先固定（因为可能性上千上万），而且每当我去改变某个事务的规则时规划需要立刻重新生成，这样的辅助控制系统就需要首先花很多时间认真分析概念以及关系——比“只会用过程思想去设计”的人能想到概念要多好几倍。Top
24 楼w_rose（w_rose）回复于 2004-10-28 14:20:28 得分 0
“看见喜欢的靶子就开枪射击”这是用数据驱动的方式去定义事务（事件）的，其它事件是否能够作为这个事件的前驱事件完全看他能够提供“喜欢的靶子”。事件不用他的所谓“前后事件”去定义，状态作为事件的条件，然后事件产生新状态，新状态然后决定新事件......
Top
25 楼mig15（米格鸡）回复于 2004-10-28 14:21:09 得分 0
我看你是书越看越傻了，
你的问题来自《企业应用构架模式》，那就拜托再看一遍，看看里面的例子(真看不出区别你就别干这行了)
为什么用领域模型理由人家也没少说啊Top
26 楼mis98ZB（Effective Typer）回复于 2004-10-28 14:29:19 得分 0
To FlyingBug：
我感觉就算有了域对象，也可能会产生事务脚本。
《企业应用构架》上不是还有一节专门讲服务层。我看那里边全是控制域对象的脚本。Top
27 楼flyingbug（Effective Refactoring）回复于 2004-10-28 14:31:09 得分 0
w_rose(w_rose)说的“检查航空发动机故障”的例子不错Top
28 楼flyingbug（Effective Refactoring）回复于 2004-10-28 14:36:15 得分 0
to：mis98ZB
这要看你怎么理解事务脚本这个词了（这个词是翻译的问题，原文是transcation script）
我觉得英文原文的范围要小很多，他指的是实现问题
而从中文字面上来看，配置文件本身定义的就是一个脚本（剧本？）
如果它定义的这个脚本代表一个具体的事务（流程？）
那就叫事务脚本，中文字面上看不出一点问题
所以我说你把书里说的这个事务脚本的语义范围放大了
由具体到抽象
所以才会觉得配置文件也是另外一种形式的事务脚本（中文看我认为没错）
Top
29 楼mis98ZB（Effective Typer）回复于 2004-10-28 14:44:04 得分 0
呵呵，我也隐约感到自己把事务脚本的语义扩大化了。
也许Martin的transcation script是指的一种特定的现象而不是脚本本身。Top
30 楼mis98ZB（Effective Typer）回复于 2004-10-28 15:28:24 得分 0
w_rose(w_rose)：
你的意思是不是分析每个事务，以便随时重组流程？
“看见喜欢的靶子就开枪射击”这个例子我不太明白。它是说类似于TCP/IP中的广播方式（感兴趣就处理/响应，不感兴趣就直接抛弃）么？
或者说，事务之间采用黑板的方式来通信？Top
31 楼ozzzzzz（希望敏捷）回复于 2004-10-28 19:24:40 得分 0
场景脱离与具体的功能，这一点在我看来是面向对象分析的特征。
而领域模型的建立自然要建立在面向对象的基础上，在这个时候关注的应该是这个世界中到底存在着什么，而不是这个世界中到底发生了什么。而实际上程序还是要去解决世界到底要发生什么的问题，但是这个解决不是利用在开始研究这些问题是如何发生的，而是研究发生这个问题的时候，这个世界中存在的对象是如何变化的。上面这些我认为还好理解，关键在于下面这个观点：谁控制这个变化。实际上很多使用面向对象方法的人，依然在做面向过程的事情，就是在回答这个问题的时候出了偏差。实际上你问这个问题就是在走面向过程的老路。在面向对象的思想中没有一个控制者存在，一切都存在于对象之间的相互关系和相互影响，而每一个对象又只关心自己，联系是建立在互相拥有和互相使用上。而你说的那个配置其实也是一种脚本，真正的场景是那些对象自由的组织的，不会去依赖一个外在的约束。
而这样做的好处在一个简单的场景中是根本体验不到，或者干脆就是感觉背道而驰的。而 w_rose说的那个检查飞机发动机的过程就很好的解释了面向对象使用场景的情况，这样一个长期的过程，又非常多的可能性，也有非常多的分支，你根本就不能用一个什么东西来控制这个流程，实际上这个流程是在对象之间互相调节的。
Top
32 楼zhouzh197895（过河小卒）回复于 2004-10-29 11:35:02 得分 0
也來學習一下。Top
33 楼mis98ZB（Effective Typer）回复于 2004-11-01 10:32:17 得分 0
想了两天，大概有些明白了。
感觉这应该是逻辑的大规模聚集（在脚本中）与按职责分散（在域对象中）的区别，其表面看起来就是我一开始画的那个图。
我一直就面向对象和面向过程在思想上（不是实现上）的区别非常迷惑。
〉〉在面向对象的思想中没有一个控制者存在
但是体系构架中有MVC存在，职责分配模式中有控制者模式存在，这些东西到底是不是面向对象的呢？Top
34 楼mig15（米格鸡）回复于 2004-11-01 11:19:00 得分 0
Carig Larman在"UML和模式应用"里说过(只记得个大概)：
理论上所有的设计模式和其他方法引入的"纯虚构"的类都是破坏OO的...
但它们有用不是？
Top
35 楼mig15（米格鸡）回复于 2004-11-01 11:23:33 得分 0
还有个例子：
有人总是叫嚣OO就要"do it self"，但都 "do it self"了还要设计模shi干嘛？Top
36 楼mis98ZB（Effective Typer）回复于 2004-11-01 15:49:22 得分 0
mig15(米格鸡)：
你的意思就是说这些东西不是面向对象的咯？
唔，一直以来都没有人就这个问题给我一个确切的答案。是不是大家也都没有把握呀？Top
37 楼mig15（米格鸡）回复于 2004-11-01 16:13:56 得分 0
面向对象的分析是一回事，实现这个系统又是一回事
OOA和OOD之间不是一一对应的关系
再说设计模式发展到现在，谁敢说它不是面向对象的？
Top
38 楼mis98ZB（Effective Typer）回复于 2004-11-01 16:21:22 得分 0
事务脚本和域模型说的都是OOD的事吧？Top
39 楼mig15（米格鸡）回复于 2004-11-01 16:28:12 得分 0
“事务脚本和域模型说的都是OOD的事吧？”
==============================================
不懂？是又怎样，不是又怎样？Top
40 楼mis98ZB（Effective Typer）回复于 2004-11-01 16:56:35 得分 0
MVC和控制者模式也都是OOD啊。
既然事务脚本和域模型说的都是OOD，MVC和控制者模式也都是OOD，那你的“面向对象的分析是一回事，实现这个系统又是一回事”又从何说起？Top
41 楼mig15（米格鸡）回复于 2004-11-01 17:00:30 得分 0
你可以用面向对象的思想来作领域分析，
但在实现这个系统是肯定会有不是OO的东西，你说什么什么究竟是不是OO,为什么要分那么清楚呢?Top
42 楼mis98ZB（Effective Typer）回复于 2004-11-01 17:21:57 得分 0
含含糊糊地用当然可以，至少能做个形似。但是我希望能有些提高。Top
43 楼mis98ZB（Effective Typer）回复于 2004-11-01 17:35:39 得分 0
呵呵，明白ozzzzzz老大的意思了。
（^_^）V
“配置其实也是一种脚本”，但是它不是事务脚本。
它只是指定对象之间的关系，并没有任何业务逻辑在它里边——业务逻辑都在域对象里边。
它只是负责组装一个大粒度的业务模块，从而生成了一个大的业务逻辑，但是它自己本身是不带业务逻辑的。Top
44 楼mig15（米格鸡）回复于 2004-11-01 19:16:26 得分 0
我一直就面向对象和面向过程在思想上（不是实现上）的区别非常迷惑。
〉〉在面向对象的思想中没有一个控制者存在
但是体系构架中有MVC存在，职责分配模式中有控制者模式存在，这些东西到底是不是面向对象的呢？
============================================================================
面向对象也有不同的流派：
至少对于控制者类，据我所知在Jacobson和ICONIX的方法中控制类也是有一席之地的Top
45 楼ozzzzzz（希望敏捷）回复于 2004-11-01 21:10:39 得分 0
我觉得初学者接触一下ICONIX的方法还是有好处的，但是如果希望针对性的提高或者面对应用他们的方法价值就要大大的缩水了。
而对于控制类的问题，实际上要具体的问题具体的研究。如果你的控制是集中的，连续的，那么往往你的这种控制类是有问题的。你要尽量做到控制类的粒度要小一些，分散一些，使控制的流动成阶段性。而最好的做法是尽量避免控制类出现在领域模型中，以尽量减少模型对现实模拟的失真。
而应该注意到的是mvc是面对对象和显示的分离而存在的一种解决方式，在领域模型中你很少会用的这种方式。实际上大家最应该了解的是领域模型更加遵守的是客观世界的规则，而不是程序结构的原则。你的很多的常用的编程技巧在领域模型之内使用要受到限制。
在我们说Framework的时候，我们实际上基本是在说技术的Framework，比如Spring,就是一个技术的框架。而实际的开发过程中，我们的软件企业还会根据所处的行业和社会的环境构建一个业务的Framework。这两个框架遵守的逻辑不同，而且它们也都可能是面向对象的。Top
46 楼mig15（米格鸡）回复于 2004-11-02 08:43:47 得分 0
领域建模时用面向对象的思维,面向对象的重点也在于此.
但在实现中就不可能有绝对纯的面向对象了，引入一些所谓的控制者类是很自然的事，设计模式里的那些**者，**器不都是些"无中生有"的类嘛Top
47 楼mis98ZB（Effective Typer）回复于 2004-11-02 11:20:42 得分 0
我理解的MVC的动机是：
同一类数据上有两类以上的正交操作，为了追求细粒度而把这些正交操作分离开。
不知道对不对？Top
48 楼mig15（米格鸡）回复于 2004-11-02 12:38:37 得分 0
我理解的MVC的动机是：
同一类数据上有两类以上的正交操作，为了追求细粒度而把这些正交操作分离开。
不知道对不对？
===============================================================================
我要骂人了!
天才把复杂的事变简单,蠢才把简单的事变复杂...
Top
49 楼mig15（米格鸡）回复于 2004-11-02 12:39:36 得分 0
我理解的MVC的动机是：
同一类数据上有两类以上的正交操作，为了追求细粒度而把这些正交操作分离开。
不知道对不对？
===============================================================================
我要骂人了!
天才把复杂的事变简单,*才把简单的事变复杂...
Top
50 楼mis98ZB（Effective Typer）回复于 2004-11-02 13:18:13 得分 0
呵呵，天才蠢才都与我无关，反正我对MVC的看法就是这样的。Top
51 楼aboush（无人居）回复于 2004-11-02 16:20:44 得分 0
为什么"无中生有"?个人觉得类似控制类都是必要的,就象是现实中的控制器一样,而且它可能是无形的,也就是说你可能受到自己也不能感觉出来的控制器的控制.
至于mvc本来就不复杂,不然的话,它怎么可能这么流行呢,一般流行的东西都比较简单.简单优雅嘛.
其实在没有mvc之前就有很多人把不同职能的类,或是模块分开,这样开发的思路清楚,层次感强,当然好处太多了.
mvc则更强调这点,他要求一定要分离不同的职能,我个人设计的时候一般不会说:哦,我这个构架是mvc......的.我一般说:哦,这个模块是负责什么职能的,开发的时候应该怎么怎么.....!
也就是说模式,构架我都只记住他为什么这么作,有什么好处,这些好处在什么时候可以发挥的最好.
一旦我觉得这里需要这样的好处,我就默认的按照那样去做.
以上是小弟的愚见,见笑了Top
52 楼mis98ZB（Effective Typer）回复于 2004-11-06 10:32:56 得分 0
嘿嘿，又有一点新想法。
域对象比事务脚本里使用的对象要更加“主动/自立”一些。
它们自己控制自己领域内的工作，而不需要一个额外的控制类/控制脚本来指指点点。
它们自己就拥有自己领域内的全部逻辑，是自己领域内的专家。（正好符合GRASP的专家模式）
这切实地贯彻了“将数据与对该数据操作的行为绑定在一起”的面向对象的指导思想。
这个“主动”的对象与《UML手册》里那个主动对象不是同一个东西，所以有些时候它被称作主动记录集。Top
53 楼w102272（Wonder）回复于 2004-11-17 21:50:50 得分 50
不太同意：“在面向对象的思想中没有一个控制者存在”或许不是否定概念本身，但在建模过程中何必非要把这个控制者干掉呢？ 它招谁惹谁了。
毕竟现在的计算机是诺依曼型的有限自动机，说到底还是个计算机器。你按下电源机器去读启动记录然后执行，那必须读启动记录是那个对象的原则？是谁给了整个系统最初的原动力和运行价值？难道是系统中某个对象的自发反应？
在很多情况下，面向过程的思路是简单而清晰的。好比你吃饭：端碗，拿筷子，挟肉，放嘴里头，吃。 如果非要定义为，人，碗，肉，嘴的复杂交互作用。那这个Job的目的性又体现在那里了？
没有必要非为了符合某个所谓的OO原则，非要把一个简单的事情当做一个包含了无数蝴蝶效应的巨系统去研究吧？这种模拟总要有个范围和程度控制才好。
Top
54 楼ozzzzzz（希望敏捷）回复于 2004-11-18 10:58:40 得分 0
w102272(Wonder)
我同意没有必要为了OO而OO。但是我们也不能就此排斥OO。
实际上面向过程的简单是建立在其扩展和维护的困难的基础上的。比如你的那个例子，如果单纯的表达吃饭，那么完全没有必要那么复杂。但是如果我们要吃药呢？我们要是喝酒呢？我们要是吃白面呢？我们要是吃瓜子呢？我们要是吃那些不知道是什么的莫名其妙的东西呢？这个时候你的那个面向过程的方法就会显示出其扩展难的短处。而当你尽一步的要考虑还要说话，还要喝水，还要呼吸，还要游泳，还要等等其他的生理作用，你的那个局部的面向过程的简单就会造成整体的面向过程的复杂。
而使用领域模型和使用脚本其实都是有其约束条件的，不是所有的地方都应该去用领域模型，也不是所有的地方都应该用脚本。首先我们需要理解脚本和领域模型的区别，才能针对性的分析究竟那一个策略才更适合你目前的环境。
其次我建议你还是应该买那个PEAA看看，会对你有很多思考的促进。Top
55 楼w102272（Wonder）回复于 2004-11-18 18:56:40 得分 0
呵呵，我的说法里头并没有把OO对立起来，我要说的还是模拟要有个范围和程度控制。
实际上一个人是可能又吃饭，又喝酒，又吃白面，又吃瓜子，又吃莫名其妙的东西，又游泳，又呼吸
但说到这个，就牵涉一个问题，无论是PO还是OO方法要解决的问题域到底是什么，这是根本性的问题。在具体环境下那种手段更复杂，也要具体看了才知道。对于具体问题来说，适合的方法才是好方法，而不是流行的方法就是好方法。你的假设要先成立才行。
别的东西不说了，我看没有什么矛盾，只是表述不同。
我上面回复想说明的只有一点“在面向对象的思想中没有一个控制者存在”这个说法我认为不对。
1.一个系统无论是采用加工还是模拟，都需要和外部环境交互，都是有边界的，不可能是一个彻底封闭的系统。无论抽象到什么程度，都需要一个给予“原动力”的启动者，这个因素不可能由内因产生。是外在环境因素推动了生物进化，而不是生物坐在那里自己进化。
2.从PO的数据加工角度看，需要一个外部控制者来调度所有的数据加工逻辑，这样才方便
从OO角度看，自己包含一个控制类来覆盖所有的状态变化和逻辑体现为一种自主处理的工作模式，
都是为了实现集中控制集中调度的原则，这没有什么不对的。虽然说没有中央控制的OO程序确实
可以工作，但稍微复杂一点的逻辑没有这种控制器逻辑的程序几乎没法想象它能够很好的工作。Top
56 楼ozzzzzz（希望敏捷）回复于 2004-11-18 21:28:19 得分 0
wonder
我再一次建议你去买一本PEAA。这样会对你有很多的启发。
实际上领域模型不是流行的东西，现在流行的是业务脚本。你去10个项目看，九个是业务脚本的。
我们说没有一个控制，并不是说没有边界。而使用控制不使用对象自身的交互，带来的问题其实与它产生的效益一样大。还是那个例子，一个控制类可以很好的解决单一的问题，如果进行扩张，比如考虑所有的用嘴的动作，那么也是可以的。但是随着不断的扩张，最后总有一天，你会发现你的领域中存在了太多的不同位置的类，你为嘴的和鼻子的其实有关系，为眼睛的也有联系，为手臂的还有。这些东西之间有些是重复的，有些是不重复的。你要花费很大的精力去维护这些东西。而这些时候你就没有使用领域模型来的简单。其实复杂的逻辑，你使用对象分解要比使用集中控制简单和方便的多。
领域模型之所以存在，并不是因为它流行，而是因为他解决了复用和复杂性的问题。这一点就和PO一样，并不能因为其不合潮流，就否认其在项目中的作用。Top
57 楼w102272（Wonder）回复于 2004-11-19 03:50:18 得分 0
首先，不要没完没了对我推荐PEAA，是否要看这本书，我自己有我的打算。
我建议你多看看高等数学的书，多看看管理的书，多看看需求分析的书，对你也一定有很多的启发。
其次，“在面向对象的思想中没有一个控制者存在”这个话是你在前面说的，可你上面的解释
却和这个说法又违背，呵呵，我已经不知道你在说什么了。 打住吧...Top
58 楼ozzzzzz（希望敏捷）回复于 2004-11-19 08:35:59 得分 0
wonder
我的意思是我们在讨论PEAA这个书到底在说些什么，所以我只能一再的建议你。你觉得我的建议过分吗？
同时也请你再仔细的看看我上面的解释，我的观点依然是原来的，在面向对象的思想中没有一个控制者存在。并不是写几个类就是面向对象了，也不是用几个模式就面向对象了。
边界不等于控制，控制也不等于需要一个从外而内贯穿整体的控制。
to all
PEAA的思想是很系统化的，不能孤立地看一个地方的单独表述，很多问题前面说了，你看不明白，你继续看，就会有答案。Top
59 楼mis98ZB（Effective Typer）回复于 2004-11-21 23:49:08 得分 0
我认为，面向对象中是没有“控制者”的角色的，但是“协调者”和“创建者”的角色是存在的。
其中，“控制者”和“协调者”之间有微妙的差异。
关于这一点，一些管理方面的书上讲述的非常清楚。
控制脚本与域模型的区别也就在这一点上。
呵呵，一点浅见，还望老大们多多指点。Top
60 楼wangxuan2001（沧海笑一生）回复于 2004-12-06 23:46:05 得分 0
学习Top
61 楼ieooo（Jet）回复于 2005-05-10 11:24:37 得分 0
学习Top
62 楼zhaoliang_chen（龙行天下）回复于 2005-05-10 22:06:18 得分 0
在哲学的范畴内 ：联系是具有普遍性的
控制是什么？ 假设你吃了一个很甜的葡萄，你能说你控制了它吗？
你还要受到它的影响，下次你看到葡萄你一定很想吃它，这就是它对你的影响。
这样看来所谓控制只是单向的联系。
世界上只有对象是客观存在的，而且正是他们的相互作用相互影响才有了业务流程
程序中的”控制“是机械的不是智能的 是受到了其他对象的影响而作出的反应
从这个角度我们不可以将它称为“控制者”
而“协调”是说对象之间的自适应能力，也就是说对象的反映能力Top
63 楼Richardhu（学无止境）回复于 2005-05-11 10:09:17 得分 0
高手说话总是很高深，但我认为能够解决问题的方法就是好方法，而且越简单越好，把问题分析的过于复杂说明你没有认清事务的本质，在解决类似使用PO还是OO，或者什么方法论上，都是不正确的，他们毕竟是种工具，我们不能说有了飞机，就应该否定或限制自行车。在特定条件下，自行车指定比飞机好。学习新的知识是必要的，但对已经存在的技术我们绝对要正确认识，加以利用，而且使用的地方比新的技术理论要多的多。
不过争论还是让我这个菜鸟学到了很多东西呀，^_^。Top
64 楼DragonLancer（龙枪骑兵）回复于 2005-05-11 12:47:48 得分 0
又是一个大问题，学习。Top
65 楼hedonister（冰戈）回复于 2005-06-14 11:47:55 得分 0
好帖啊，markTop
