我认为POJO是一个错误的概念

 

            这篇内容其实没有经过太多的深思熟虑，只是个人一时的感觉。从个人风格上来讲，我倾向简单质朴的设计开发理念；从方法论上，我更加倾向自顶向下的设计；从做事情的目标上来看，我追求质量优先，更愿意使用较为保守和稳妥的理念和方法。

 

       看了一些J2EE和Java/web开发方面的内容，说个个人的感受和不客气的话，感觉POJO这东西就相当于C语言的struct了，完全把面向对象这一个概念给糟蹋了。

      换句话是，这个概念的产生本质上就是荒谬和毫无意义的。我之前读《重构》时，非常欣赏Martin Fowler，现在我觉得他更多是炒概念和名词。

    从 面向对象的精神实质上来讲，一个类，应该有什么方法，由其业务层面的定义出发来分析的。举个例子，例如Admin这样一个类，自然拥有修改自身口令的方法 changePassword，自然拥有“修改自身信息”的方法，modifySelfInfo()，不管你什么POJO还是EJB，还是Spring里的Bean，什么充血模型、贫血模型。

       所谓“数据对象”这个词，实际上是从技术的观念和实现方法，给上推到设计领域的，这种“上推”不是很好的一种路子，设计应该不被实现技术所绑架，应该是从业务领域去分析。

       我相信，不管设计开发的方法论发展到了什么时候，都需要从事物（或者系统，或者产品）的本质出发，来分析、设计、实现。

 

         或者说，业务逻辑应该放在哪里？我认为这是一个伪问题，或者说不成为问题。因为业务层面上在哪里，设计实现的时候也就在哪里。上面的例子已经说清楚了。

 

      

 

 

 

 

 

评论

2 楼 windshome 2013-07-03  

问题就是这样的，你的意思我明白。问题是概念和模型应该从哪里来？

物有本末，事有终始。概念和模型应该从业务需求和场景中来，去指导后续的设计开发，而不应该由实现去反推到设计领域。

我在之前的一篇博文里提到，例如一个产品中，概念、架构、模块和设计之间的一个数量关系。在一个产品中，概念数<架构的数量<模块的数量<实现的数量。


比较好的一种做法，如果要解决一个新的问题，最好是在原来已经有且经过锤炼的架构上，增加一些包或者是组件完成；实在不行的话，在原有概念的基础上，创造新的架构，解决该问题；最不好的是选择，是创建一组概念，再到架构，再到实现。

因为这样造成的结果，就是概念泛滥，概念不够精炼。是属于务虚的做法。

1 楼 luopozhuihun 2013-07-03  

你说的没错，真正的设计没有那没多条条框框
但是概念无疑很重要，因为每个人的思想千差万别，而软件开发、尤其是大型软件，需要的是团队合作，有一个大家都接受和理解的概念与模型在这个层面上至关重要。