我与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里才能看到更好，更能眼前一亮的答案。

同意你老师的说法。

OO是一种思考问题的方式，我们可以用OO的思想去分析问题，设计你的系统，如何落实到具体项目就要看具体情况。

不用纠结，等你到了你老师的程度，你就能明白他的意思了。

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

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

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

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

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

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

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

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

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

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

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

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

最烦这种帖子

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

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

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


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

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

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

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

看来答案如此！

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