我与OO老师的问答（SSH与OO可以兼得吗），邀你继续...
问：面向对象的设计、开发 与 实际工作中的规范化、流程化、定型化 架构之间的矛盾，如何处理？如何使OOA、OOD实战化，特别是在水平各异的整个团队中普遍展开
答：规范化、流程化、定型化与面向对象的设计、开发没有绝对矛盾。开发规范中文书中都把UML的使用模板化了，反而更利于面向对象的设计、开发。或许面向对象更适合迭代式开发，但是瀑布似的规范化、流程化、定型化一样可以使用面向对象。在团队中，水平最高的架构师做OOA，设立整体的规范模板，次之的做OOD，再次之的做OOP，水平各异的团队要保证高水平对低水平人员的足够的review
问：开发规范文书中所定义的模板化的东西，都是共性的东西，是“放之四海而皆准”的东西，它不可能知道我要做的一个项目的其中一个业务是什么样子的。
也就是说，它仅仅能做到框架结构是OO的。我的问题是，如何才能让业务也OO起来呢？比如，课上例子中办理旅游申请这个业务，把申请单和申请人都作成相应的Class。而到了另外一个页面，比如导游回来后要报销，那么报销的科目可能是一个Class。这时候，没有哪个文书或生成工具可以帮助我们。反而，如果我们按照课程中教授的UML方法去给这些业务建模的话，得到的那些Class，又当如何安放到我们的框架规范当中去呢？
答：业务的OO，要在问题域，也就是业务的现实世界模拟抽象出概念模型来，这个概念模型，也就是有概念类组成的，与现实世界的业务是能够一一映射的，有了这个模型，我们就可以OO下去。
问：一个成型的框架，比如 MVC，比如3层结构，已经规定好了，数据通过POJO保存，业务逻辑在Service中，这样Service也好，数据持久层的DAO也好，都成了贫血对象，在有些架构中它们甚至是单例的。POJO是它们之间调用时的参数或返回值。
于是，从结构来看，3层之间各司其责，互相关联；不同POJO也可能有聚合甚至组合关系，这是OO呀。
但是，从业务角度看，通过参数传递数据，通过函数进行运算，这不就是彻头彻尾的PO吗？
所以，“我们就可以OO下去”，到底该如何去做呢？
答：其实我们做一个业务，没有必要彻头彻尾的OO，业务的概念模型OO了，依照成熟的框架把各层的接口设计的OO了，这样就够了。至于具体到每个层次的某一模块，我完全可以是PO的思维来实现的。关键是现实的业务到概念模型的OO映射，概念模型到设计模型的OO映射。到具体的细节实现，不必纠结的
回答到这里，老师将帖子关闭了，但是，我的疑惑才刚刚说到关键的地方。
我还想继续问：那我们上完课，再遇到一个类似 旅行社OA 的项目，还是没法把课上学到的 建模 理论应用在项目中呀？
我承认，我所指的框架，很大程度上受到了SSH的影响。或者说在SSH里，业务如何OO起来？
我想也就是JE里才能看到更好，更能眼前一亮的答案。
public ModelAndView queryHistory(HttpServletRequest request,HttpServletResponse response) throws Exception {HashMap<String,Object> returnMap = ***Manager.query***List(request);return new ModelAndView("ajax_***", returnMap);}
27 楼 seele 2011-01-13 gdpglc 写道没人说一定要用。而且现在大部份人都没用。因为它难用，而且大部份人用的是Spring。
好处坏处看经典吧，我说不出新东西。
你这个例子，好象不明显，而且我也不太理解你的需求。我举个别的吧，比如转帐。
从 A帐户取transferNum到B。
以下代码，只表语意
面向过程的方式：
//transaction begin
Account a=AccountDao.find......
a.setBalance(a.getBalance-transferNum);
AccountDao.save(a);
Account b=AccountDao.find......
b.setBalance(b.getBalance+transferNum); 业务
AccountDao.save(b); 持久化
//transaction end
面向对象的方式：
Account类提供如下方法：
void transferTo(Accout a,transferNum){
this.balance-=transferNum;
a.balance+=transferNum;
}
然后Service 里这样用：
//事务开始
Account a=获得Account
Acconnt b=获得Account
a.transferTo(b,50);
//事务结束
混着写
Account 是个实体，本身的业务是由人给予它含义的，所以不建议放到属于自己的类里实现transferTo 28 楼 gdpglc 2011-01-13 领域对象来自于领域，业务逻辑也来自领域。所以才有 Domain Driven Design的理论。 29 楼 treblesoftware 2011-01-13 没看透的人对这些比较有兴趣吧。 30 楼 njyu 2011-01-13 说和做两回事 31 楼 liujickson 2011-01-14 TonyLian 写道问：面向对象的设计、开发 与 实际工作中的规范化、流程化、定型化 架构之间的矛盾，如何处理？如何使OOA、OOD实战化，特别是在水平各异的整个团队中普遍展开
答：规范化、流程化、定型化与面向对象的设计、开发没有绝对矛盾。开发规范中文书中都把UML的使用模板化了，反而更利于面向对象的设计、开发。或许面向对象更适合迭代式开发，但是瀑布似的规范化、流程化、定型化一样可以使用面向对象。在团队中，水平最高的架构师做OOA，设立整体的规范模板，次之的做OOD，再次之的做OOP，水平各异的团队要保证高水平对低水平人员的足够的review
问：开发规范文书中所定义的模板化的东西，都是共性的东西，是“放之四海而皆准”的东西，它不可能知道我要做的一个项目的其中一个业务是什么样子的。
也就是说，它仅仅能做到框架结构是OO的。我的问题是，如何才能让业务也OO起来呢？比如，课上例子中办理旅游申请这个业务，把申请单和申请人都作成相应的Class。而到了另外一个页面，比如导游回来后要报销，那么报销的科目可能是一个Class。这时候，没有哪个文书或生成工具可以帮助我们。反而，如果我们按照课程中教授的UML方法去给这些业务建模的话，得到的那些Class，又当如何安放到我们的框架规范当中去呢？
答：业务的OO，要在问题域，也就是业务的现实世界模拟抽象出概念模型来，这个概念模型，也就是有概念类组成的，与现实世界的业务是能够一一映射的，有了这个模型，我们就可以OO下去。
问：一个成型的框架，比如 MVC，比如3层结构，已经规定好了，数据通过POJO保存，业务逻辑在Service中，这样Service也好，数据持久层的DAO也好，都成了贫血对象，在有些架构中它们甚至是单例的。POJO是它们之间调用时的参数或返回值。
于是，从结构来看，3层之间各司其责，互相关联；不同POJO也可能有聚合甚至组合关系，这是OO呀。
但是，从业务角度看，通过参数传递数据，通过函数进行运算，这不就是彻头彻尾的PO吗？
所以，“我们就可以OO下去”，到底该如何去做呢？
答：其实我们做一个业务，没有必要彻头彻尾的OO，业务的概念模型OO了，依照成熟的框架把各层的接口设计的OO了，这样就够了。至于具体到每个层次的某一模块，我完全可以是PO的思维来实现的。关键是现实的业务到概念模型的OO映射，概念模型到设计模型的OO映射。到具体的细节实现，不必纠结的
回答到这里，老师将帖子关闭了，但是，我的疑惑才刚刚说到关键的地方。
我还想继续问：那我们上完课，再遇到一个类似 旅行社OA 的项目，还是没法把课上学到的 建模 理论应用在项目中呀？
我承认，我所指的框架，很大程度上受到了SSH的影响。或者说在SSH里，业务如何OO起来？
我想也就是JE里才能看到更好，更能眼前一亮的答案。
32 楼 Frankie199 2011-01-14 你是在怀疑老师，还是怀疑你自己，呵呵 33 楼 TonyLian 2011-01-14 感谢各位的讨论，受益匪浅。
尤其是 gdpglc peterwei 两位，虽然昨晚我没能上线，但是今天一早就搬板凳听两位讲课。gdpglc 的那段分别 PO和OO 的代码，其实正是我想问的问题。
让大家见笑了~
34 楼 wu_quanyin 2011-01-14 怎么看怎么像做学术论文似的。。。 35 楼 hatedance 2011-01-14 <p>Spring和DDD是没有必然联系的。</p>
<p>不会DDD，照样拿来spring，分3层进行web开发。</p>
<p>但是如果你学习了DDD，结合spring，也挺好的，就是你所谓的OO，所谓的非贫血。</p> 36 楼 leexhwhy 2011-01-14 peterwei 写道gdpglc 写道没人说一定要用。而且现在大部份人都没用。因为它难用，而且大部份人用的是Spring。
好处坏处看经典吧，我说不出新东西。
你这个例子，好象不明显，而且我也不太理解你的需求。我举个别的吧，比如转帐。
从 A帐户取transferNum到B。
以下代码，只表语意
面向过程的方式：
//transaction begin
Account a=AccountDao.find......
a.setBalance(a.getBalance-transferNum);
AccountDao.save(a);
Account b=AccountDao.find......
b.setBalance(b.getBalance+transferNum);
AccountDao.save(b);
//transaction end
面向对象的方式：
Account类提供如下方法：
void transferTo(Accout a,transferNum){
this.balance-=transferNum;
a.balance+=transferNum;
}
然后Service 里这样用：
//事务开始
Account a=获得Account
Acconnt b=获得Account
a.transferTo(b,50);
//事务结束
ok,我终于理解你的意思了。说得那么绕。哈哈。你直接说充血，就是在Domain Object里把逻辑操作和数据都封装在一起。但这种做法，我是持反对观点的，也不提倡。
action-->service(什么也不做，只管事务之类)-->domain object(里面有操作和属性)--dao
没有疑问了。这样的缺点我说说：
1.domain object和dao形成了双向依赖，复杂的双向依赖有可能产生很多潜在的问题。
2.你这样做会让大家产生很在的误会，导致整个结构的混乱无序。这个是service呢还是domain object呢？
3、service层必须对所有的domain object的业务逻辑提供相应的事务封装方法，太重复了,看着就不爽。比如你service里肯定还有个和object类似的方法transfer。何必多此一举。直接贫血不就行了，这样pojo还简单些。
我的结论，你何必一定要这种充血oo方式，难道就为了完全的oo？java里贫血不挺好的嘛，大家都这么用。
1，DDD的充血模型就一定会出现domain object和dao的双向依赖？不一定吧。
2,团队对DDD的理解确实会出现一些混淆，但是学习任何技术都是需要付出代价的。
3：service不一定出现和domain object对应的方法吧，可以参考DCI理论中动态织入或者事件的机制吧。
个人观点，java开发中使用spring，想充血确实很难，关键是对象的状态怎么维护和控制。向EJB似的搞个容器？太重了吧。并且面向过程也没有什么错吧，至少这么多项目都是这么做的。
所以针对楼主的疑惑，框架级别还是要OO的，业务分析设计也是需要OO的。复杂的业务场景也是需要OO的。至于Service，pojo，dao，action等等，不要管他是OO还是面向过程。just do it！
37 楼 魔力猫咪 2011-01-14 建议还是多看一下领域驱动设计方面的书籍。充分理解一下应用层和领域层的划分，服务、领域对象和值对象的关系。
Spring也不是没有充血模型的，Spring Roo就是充血的。
38 楼 zhmiao 2011-01-14 搞这么抽象的东西，代码写出来可维护性强就OK了。 39 楼 H_eaven 2011-01-14 leexhwhy 写道peterwei 写道gdpglc 写道没人说一定要用。而且现在大部份人都没用。因为它难用，而且大部份人用的是Spring。
好处坏处看经典吧，我说不出新东西。
你这个例子，好象不明显，而且我也不太理解你的需求。我举个别的吧，比如转帐。
从 A帐户取transferNum到B。
以下代码，只表语意
面向过程的方式：
//transaction begin
Account a=AccountDao.find......
a.setBalance(a.getBalance-transferNum);
AccountDao.save(a);
Account b=AccountDao.find......
b.setBalance(b.getBalance+transferNum);
AccountDao.save(b);
//transaction end
面向对象的方式：
Account类提供如下方法：
void transferTo(Accout a,transferNum){
this.balance-=transferNum;
a.balance+=transferNum;
}
然后Service 里这样用：
//事务开始
Account a=获得Account
Acconnt b=获得Account
a.transferTo(b,50);
//事务结束
ok,我终于理解你的意思了。说得那么绕。哈哈。你直接说充血，就是在Domain Object里把逻辑操作和数据都封装在一起。但这种做法，我是持反对观点的，也不提倡。
action-->service(什么也不做，只管事务之类)-->domain object(里面有操作和属性)--dao
没有疑问了。这样的缺点我说说：
1.domain object和dao形成了双向依赖，复杂的双向依赖有可能产生很多潜在的问题。
2.你这样做会让大家产生很在的误会，导致整个结构的混乱无序。这个是service呢还是domain object呢？
3、service层必须对所有的domain object的业务逻辑提供相应的事务封装方法，太重复了,看着就不爽。比如你service里肯定还有个和object类似的方法transfer。何必多此一举。直接贫血不就行了，这样pojo还简单些。
我的结论，你何必一定要这种充血oo方式，难道就为了完全的oo？java里贫血不挺好的嘛，大家都这么用。
1，DDD的充血模型就一定会出现domain object和dao的双向依赖？不一定吧。
2,团队对DDD的理解确实会出现一些混淆，但是学习任何技术都是需要付出代价的。
3：service不一定出现和domain object对应的方法吧，可以参考DCI理论中动态织入或者事件的机制吧。
个人观点，java开发中使用spring，想充血确实很难，关键是对象的状态怎么维护和控制。向EJB似的搞个容器？太重了吧。并且面向过程也没有什么错吧，至少这么多项目都是这么做的。
所以针对楼主的疑惑，框架级别还是要OO的，业务分析设计也是需要OO的。复杂的业务场景也是需要OO的。至于Service，pojo，dao，action等等，不要管他是OO还是面向过程。just do it！
这个只是个伪劣的OO吧,就不要往OO上靠了吧.
40 楼 gdpglc 2011-01-15 zhmiao 写道搞这么抽象的东西，代码写出来可维护性强就OK了。
从用户需求到可维护的代码，中间是有一段距离的。没有软件设计方法论的指导，靠灵感得到可维护的代码，是不靠谱的。 41 楼 treblesoftware 2011-01-15 gdpglc 写道zhmiao 写道搞这么抽象的东西，代码写出来可维护性强就OK了。
从用户需求到可维护的代码，中间是有一段距离的。没有软件设计方法论的指导，靠灵感得到可维护的代码，是不靠谱的。
笑死我了，你是没遇见一些软件模型，有些业务使用DDD或者充血模型这些浮云的东西根本无法解决，那时你才知道，在这里夸死OO是多么的幼稚和可笑，如果用OO搭建一个DEMO还可以，神论也就是这么出来的。
不同的模型和架构采用不同的软件设计方法才是真正可行的，系统才会变得清晰可见，没有一种方法可以完全满足各种模型，因为现在的软件平台和思想决定了这一切。
