面向对象现状

书中作者发现了一个现象，很多j2ee设计背离了oo原则：认为持久对象不应该包含任何行为。

作者认为仅仅暴露getter和setter的对象不是真正的对象，一个对象应该包含除了属性外还应该包含这个对象的行为。

联想到学过的所有对面向对象编程的解释，发现貌似真是如此。面向对象编程：所有的分析、设计、开发都以对象为基础。而对象又是什么呢，对象是现实中存在的抽象，是具体实物的逻辑表现。如果对马做抽象，我们自然的会发现：它有四条腿，它可以跑。

但是工作这么久却发现，国内流行的mvc，流行的三层，很多都不是面向OO的。

很多遗留项目中分三层后，只是根据行为做了横向切分：模型层就是一个个持久化对象，控制层就是一个个action或controller，表现层就是html或者jsp，一个业务对应一个或者多个action，后面跟着多个biz，和多个dao。每个对象要么全是方法，要么全是引用，或者全是属性，或者更狠的混成一团。现在想来，这TMD根本不是面向对象啊。。。这是面向过程啊。。。

也许项目在设计初始是根据对象设计的，但是后期业务添加或者修改后，已经通过代码看不到马有几条退，马是怎么跑的。。。

这就是我看到的国内OO现状，没有人注意到代码是什么，大家都在看功能实现了没，但是这种偏离设计原则的代码，维护性真的值得思考。。。

评论

2 楼 zhangyatong 2014-12-24  

xiaokek 写道

个人砖头，仅供引玉：
1、项目中分三层，是在系统框架层面做了符合面向对象思维的设计，它把每个业务的控制器抽象成一个个Action，这个控制器接受参数，转发请求给biz层（也有叫service层的），最后返回结果，指定视图

是啊，国内对开发要求更多的是，快速上手，快速完成功能。开发会按要求写某个逻辑的时候就去看相应代码，改完ok收工。多高效。。。项目迭代一个月后自己看写过的代码也搞不懂了，变得小心翼翼。再久一点就变成无人敢动了。好一点的会抽象些类和方法，然后下一次迭代 。但是，很少有人想过，要根据对象来实现。。。不知道到什么时候国内才会改变这种方式。。。也许“面向对象”成本比较高吧。呵呵，好好学习，谢谢@xiaokek的分析

1 楼 xiaokek 2014-12-21  

个人砖头，仅供引玉：
1、项目中分三层，是在系统框架层面做了符合面向对象思维的设计，它把每个业务的控制器抽象成一个个Action，这个控制器接受参数，转发请求给biz层（也有叫service层的），最后返回结果，指定视图。
2、而业务逻辑层（biz层），一般都是一堆业务逻辑的堆叠，接受Action给它的参数，完成指定的任务即可，需要持久化数据时，再转发给dao去查询和存取。所以biz层在代码结构层面是被抽象成用于处理真正业务逻辑的组件。

这样设计的好处是：
1、所有业务的处理全部统一为以上说明的一套完全一样的处理流程，负责具体业务逻辑开发的程序员无需考虑其他，只需关注业务逻辑代码的编写即可。
2、其他程序员看到同样结构的代码层次，更容易理解和上手。我接触到的一部分程序员看到一些不是action，biz，dao的包，因为不能迅速理解，会觉得有学习上的阻力，因而排斥。

这样设计的缺陷是：
1、因为系统业务逻辑的复杂度高和变化过快，容易在biz层陷入面向过程式的处理，过多的if语句，过于复杂的逻辑处理，导致博主所说的“混成一团”的状态。

我的理解，在业务逻辑层是有很多东西可以挖掘的，可以用表驱动设计去消灭过多的if，用各种短小只做一件事的方法来封装逻辑，减小复杂度，还有很多写出好代码的方法，不一一列举了。我觉得题主最后想表达的意思应该是大家都应该多学习学习，应该怎么样写出“好的没有异味”的代码。