我与OO老师的问答（SSH与OO可以兼得吗），邀你继续...

我还是不明白，你说的这句是什么意思？
我再说一次,订单，客户，什么明细类这些是针对领域模型的OO设计，而这些是企业业务应用的重要组成部分和抽象，做设计的时候当然首先考虑企业的OO模型。SSH这些是具体的东西，是框架，做这些就是具体的OO设计实现。框架和设计实现做得怎么样，要看一个人的水平。老师也有可能没有研究过这些框架的实现，也不知道框架的OO设计，你让他怎么给你讲？
我们来回顾一下OO：
OO原则：Abstraction（抽象）
Encapsulation（封装）
Modularity（模块化）
Hierarchy（分层）

面向对象设计五大原则
单一职责原则(Single-Resposibility Principle)。
开放封闭原则(Open-Closed principle)。
Liskov替换原则(Liskov-Substituion Principle)。
依赖倒置原则(Dependecy-Inversion Principle)。
接口隔离原则(Interface-Segregation Principle)。

Object Oriented Analysis
用面向对象方法分析问题域，建立基于对象、消息的业务模型，形成对客观世界和业务本身的正确认识。
生成业务对象的动、静态模型和抽象类。

Object Oriented Design
针对OOA给出的问题域模型，用面向对象方法设计出软件基础架构（概要设计）和完整的类结构（详细设计），以实现业务功能。
生成对象类的动、静态模型（解决域）。

你想想看，在这些框架的设计与实现中，是不是用了各种设计模式，大师们是不是用了上面这些OO的东西？

ok，大师们的太高深，我们可以暂时不去想它们。那么我们再来看看我们日常的struts,service,dao：
1.平常在jsp里面填一大堆表单，用了sturts,是不是在action类中放一个model接收这些数据，这算不算是封装？
2.我们区分action,service,dao,这是不是oo原则里的分层？
3.我们在用spring的依赖注入，比如service类中的setDao,getDao,是不是把恶性依赖转成良性依赖，是不是OO的应用？
4.我们在画时序图时，从action-->service-->dao层，是不是传递Domain Object,是不是一种依赖关系，是不是通过消息传递？那么是不是用了oo分析：建立基于对象、消息的业务模型？
5.我们在设计dao类时，是不是一个dao类只做增删改查的事情？在一个service类里，是不是只关注单个业务的一些操作？这是不是应用了单一职责的原理？ok,当然还有很多。我就当复习和总结OO了。哈哈。

spring struts hibernate 本身是OOP的。 但是业务逻缉不是OOP的。想一下你怎么表达业务逻缉的。是不是：
第一步取这个数据做这样那样的运算
第二步取那个数据做这样那样的运算

然后这些放到Service和Dao里。这就是面向过程。

如果一个业务逻缉是：
第一步：给某个领域对象发消息，让它做去
第二步：给某个领域对象发削息，让它做去

这是面向对象的。领域对象里是有逻缉的，即充血。

OO的最终目的就为了代码的可重用，可维护，可扩展。我想分层也是

说的很好啊~+1,我再来扯2句,简单说,就是一切皆对象,并不仅仅是业务逻辑是oo的~书上总拿个业务逻辑来做例子,是为了方便理解~

它们都是服务于业务过程的数据。基本上是如下公式：

业务逻缉=业务过程+业务数据

业务过程和业务数据是明显分开的。这就不是面向对象，是面向过程的。

综上几位的意思
1）框架内部是OO的，这个无疑
2）使用SSH框架时，只能PO（即 想充血也充不起来）

另，我认为，peterwei 最后用绿色文字说的5点，都是只是技术角度看上去的OO。
action、service、dao、domain。。。这些都是技术词汇

而gdpglc 引用的robin 的话，恰恰说明了，从业务角度看上去的OO，
如：订单、客户。。。 在SSH架构里，是没法做到充血的。

它们只能作为贫血的domain object。

我开始就是想不明白，如何在 客户Class里写 public 订单 make订单() 这样的充血方法。现在 Robin 已经给了结论——这是不可能的。

换句话说，在SSH里，死了那条心吧，业务分析时话的类图，就只当是为自己整理思路吧，进入编码阶段它们就用不上了。

OOA对于分析领域问题是很有效的。我觉得OOA本身并不是为了OOD和OOP存在的。在现实的需求分析过程中。第一个难点根本不是如何实现软件，而是如何理解用户的领域。这时OOA的方法论是有效的。

但是OOA的结果，如何变成实际的软件，是另一回事了。

你这样说行不通，举个例子：支付

service里的方法：
savePayment(Payment p){
 //我们都是调用相关service类操作
  paymentDao.save(p);
 //封装消息通知接口支付
  messageService.sendMessage(message notice);
  logService.log(...);
}

实际的支付接口方法可能是：
receiveMessage(..){
  //parse message
  userService.findAccountByUser(...);
  billService.bill(XXX); 
  accountService.save(account);  
}

这算不算：给某个业务对象发消息，让它做去？是不是面向对象？

那么具体操作的复杂逻辑肯定要一步步来，总要有个地方做。

你说的东西，一直说得不够清楚。这个是指什么？


为什么用不上？我就不明白。你是怎么个用不上法，你举个实例的例子来说说。

为什么一定要充血，你们说的充血是什么概念？pojo不能满足你们的需求？


我们先不讨论robin说的结论对不对。为什么他说的就是不可能的，他是神吗？你有没有经过自已的思考？

关键是业务逻缉是由谁来做。 Service Dao是过程对象，换句话说，这只是功能的简单划分。Service和Dao都可以是单粒的，几乎没有属性，这样的对象相当于一个名子空间。


我之前说业务对象，说的不准确。我是指领域对象。比如：对于支付，会有Account，那Account就是领域对象。要让它充血才是采用了面向对象分解。


总之：
业务逻缉=业务过程+业务数据
就是面向过程的。

Java Eye有专门讨论领域模型的地方，建议多到那里看看牛人贴。