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

TonyLian

浏览: 401496 次
性别:
来自: 北京

最近访客更多访客>>

Janler

white_crucifix

linkoog

stonegreen

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

【编程技术】

OO SSH DAO 框架 Spring

问：面向对象的设计、开发与实际工作中的规范化、流程化、定型化架构之间的矛盾，如何处理？如何使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里才能看到更好，更能眼前一亮的答案。

分享到：

关于项目管理的通俗讲解 | 实战Ext -> Struts2 -> Spring数据传递与解 ...

2011-01-13 13:46
浏览 2888
评论(41)
论坛回复 / 浏览 (41 / 29268)
分类:编程语言
查看更多

21 楼 gdpglc 2011-01-13

没人说一定要用。而且现在大部份人都没用。因为它难用，而且大部份人用的是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);
//事务结束

20 楼 peterwei 2011-01-13

gdpglc 写道

peterwei 写道

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);  
}

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

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

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

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

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

那我倒想听听你的充血实现方式，那么你给我举个充血OO的支付代码实现。充血有什么优势？为什么一定要用？
1.用户支付
2.消息通知支付接口
3.接收消息
4.找出账户
5.计费相关
6.保存账户

19 楼 gdpglc 2011-01-13

peterwei 写道

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);  
}

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

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

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

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

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

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

18 楼 peterwei 2011-01-13

TonyLian 写道

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

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

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

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

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

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

引用

客户Class里写 public 订单 make订单() 这样的充血方法。

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

引用

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

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

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

引用

现在 Robin 已经给了结论——这是不可能的。

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

17 楼 peterwei 2011-01-13

gdpglc 写道

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

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

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

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

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

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);  
}

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

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

16 楼 gdpglc 2011-01-13

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

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

15 楼 TonyLian 2011-01-13

14 楼 gdpglc 2011-01-13

TonyLian 写道

LS问的好！但这个和OO有什么联系呢？

我也是这个疑问，但这个和OO有什么联系呢？

SSH里的dao,service,action,页面jsp都可以通过代码生成器生成（其实这些生成器我已实现了）

但是，当我学习到建模的时候，课程中讲述的几乎没有是对框架建模的，
什么 Service里要关联DAO，或者依赖注入。。。

而是都在讲业务建模，什么订单类要关联客户类，付款通知类要聚合付付款详细类，等等。。。

我是不明白，这些订单、客户、付款通知、付款明细Class，如何出现在dao,service,action,这样的体系中？它们都是Service？都是POJO？显然都不合适。

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

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

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

13 楼 sydra 2011-01-13

peterwei 写道

TonyLian 写道

我还是不明白，你说的这句是什么意思？
我再说一次,订单，客户，什么明细类这些是针对领域模型的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了。哈哈。

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

12 楼 luckaway 2011-01-13

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

11 楼 gdpglc 2011-01-13

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

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

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

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

10 楼 peterwei 2011-01-13

TonyLian 写道

9 楼 mingjian01 2011-01-13

TonyLian 写道

我个人认为，业务上的OO跟SSH没有什么关系， OO设计应该是一种思想，而究竟是业务设计和技术框架设计没关系。
比如要业务上设计好了概念类，有订单，客户等，概念类又对应一个或者多个Class，但是放在hibernate中时，hibernate不会理会你save的究竟是什么业务类，它一点也不关心。因为hibernate本身的OO设计中只是关注持续化对象。所以业务的OO设计跟技术框架的OO设计一点也没有关系，但是OO设计对技术框架的设计和业务框架的设计都是通用的，都要抽取可变的概念类，都有OO的设计模式。LZ学习的应该是一种通用的设计方法，忘记业务和框架吧

8 楼 TonyLian 2011-01-13

【如果你用的是Spring，没啥说的，必须贫血，你想充血也充不起来；】

看来答案如此！

7 楼 gdpglc 2011-01-13

TonyLian 写道

感觉我的问题是具体的，而老师的回答都是“太极”的。

而这么一个具体的问题不弄清楚，如何能练就“太极”！？

在SSH框架下，开发一个OA（先不上升到工作流）系统，如何OO的把，人员、事宜等都落实？

在UML工具中画的类图如何变为现实的代码？如果用工具直接生成代码，如何放到SSH当中去呢？

所谓让业务逻缉OO，我想就是充血模型。引用一下Robin的话：

robin 写道
如果你用的是Spring，没啥说的，必须贫血，你想充血也充不起来；
如果你用的是RoR，也没啥说的，直接充血，你想贫血也未必贫得下来；

实际上，让业务逻缉OO，对于SSH是有困难的。

现在的项目在实现时，业务逻缉主要都是以面向过程的方式表达的。

而且，面向过程的表达方式，是有其优点的。最主要的就是很容易被大众接受和理解。我觉得你问的问题很好，我刚工作时，也一直纠结在这个问题上。后来终于明白，其实大家都在面向过程开发...

6 楼 WorldHello 2011-01-13

TonyLian 写道

最烦这种帖子

你看看ssh的源码，那个不oo？

5 楼 nighthawk 2011-01-13

我不装，说句实话，确实是太极。分析时搞得有模有样。
做起来全是老一套。

4 楼 TonyLian 2011-01-13

3 楼 peterwei 2011-01-13

TonyLian 写道

我就不清楚你想要干嘛？OO和SSH有什么必然关系吗？一个是设计，一个是框架。
如果你是想要模型生成代码呢，我可以告诉你。Rose和Enterprise Architect这些建模工具都可以直接把设计好的模型生成代码，前提是你包的路径要和SSH想要的结构一样。
如果你还想更轻松些，点一下就生成所有的什么dao,service,action,页面jsp模板，那么你要自已写一下代码生成工具。
但这个和OO有什么联系呢？

2 楼 TonyLian 2011-01-13

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论