【Java-POJO-设计模式】JavaEE中的POJO与设计模式中多态继承的冲突
POJO的名称有多种，pure old java object 、plain ordinary java object 等。
按照Martin Fowler的解释是“Plain Old Java Object”，从字面上翻译为“纯洁老式的java对象”，但大家都使用“简单java对象”来称呼它。
POJO的内在含义是指那些没有从任何类继承、也没有实现任何接口，更没有被其它框架侵入的java对象。
二：为什么会有POJO？
主要是Java的开发者被EJB的繁杂搞怕了，大家经过反思，又回归“纯洁老式”的JavaBean，即有无参构造函数，每个字段都有getter和setter的java类。
三：POJO的意义
POJO让开发者可专注于业务逻辑和脱离框架的单元测试。除此之外， 由于POJO并不须要继承框架的类或实现其接口，开发者能够极其灵活地搭建继承结构和建造应用。
POJO的意义就在于它的简单而灵活性，因为它的简单和灵活，使得POJO能够任意扩展，从而胜任多个场合，也就让一个模型贯穿多个层成为现实。
先写一个核心POJO，然后实现业务逻辑接口和持久化接口，就成了Domain Model； UI需要使用时，就实现数据绑定接口，变成VO（View Object）。
四：POJO与PO、VO的区别
POJO是指简单java对象（Plain Old Java Objects、pure old java object 或者 plain ordinary java object）。
PO是指持久对象（persistant object持久对象）。
VO是指值对象或者View对象（Value Object、View Object）。注意，本文的VO特指View Object。
持久对象实际上必须对应数据库中的entity，所以和POJO有所区别。比如说POJO是由new创建，由GC回收。但是持久对象是insert数据库创建，由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库Connection之中，Connnection关闭以后，持久对象就不存在了，而POJO只要不被GC回收，总是存在的。
由于存在诸多差别，因此持久对象PO(Persistent Object)在代码上肯定和POJO不同，起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要PO在使用上尽量和POJO一致，对于程序员来说，他们可以把PO当做POJO来用，而感觉不到PO的存在。
五：POJO的扩展
POJO仅包含最简单的字段属性，没有多余的东西，它本质上就是一个普通的JavaBean。
但是在POJO的基础上，能够扩展出不同的对象。
为POJO增加了持久化的方法（Insert、Update、Delete……）之后，POJO就变成了PO。
为POJO增加了数据绑定功能之后，POJO就变成了View Object，即UI Model。
为POJO增加业务逻辑的方法（比如单据审核、转帐……）之后，POJO就变成了Domain Model。
POJO还可以当作DTO使用。
我一直认为：概念，名词，理论无非是人用来理解、抽象事物的，是拿来用的。如果没有相应的名词，我们自己也可以创造。
个人感觉，在SSM或SSH的 JavaWeb 项目中，领域模型【Domain Model】（如成绩管理系统里面的学生、成绩等实体） 一般是被简化为 POJO ，然后这个 POJO 既用作 VO 也用作 PO 。Struts 或 Sprint MVC 用 VO 来包裹页面的数据，传给 Action 或 Controller ； Action 或 Controller 内部 用 DTO【Data Transfer Object 】互相传输数据； Hibernate 或者 MyBatis 用 PO 来包裹 业务逻辑处理过的数据 放到 数据库中。在这里，VO 和 PO 因为简单，就使用同一个 POJO 了事。但是如果我们遇到复杂的 领域模型，这个需要使用 继承和多态的 结构应该放在哪里呢 ？ POJO ？ PO？VO？DTO？我觉得，这时候，是不是就应该需要另外一层 ？
举个在《设计模式：Java语言》中的“状态模式”的例子。
有个传送带，它有一个用于放入物品的门和控制门开关的按钮。当门关着时，按钮开门；当门开着时，按钮使门继续保持打开；当门开着，且2分钟没有操作时，门自动关闭；当门正在关闭时，按钮使门打开；当门正在打开时，按钮开门。【具体细节忘了。。。】
博主：简单的说，就是按钮总是要开门，门超时会自动关闭。门除了开关两个状态，还有“正在开 Opening ” 和 “正在关 Closing”两个状态。
书中建议使用 状态模式，也就是说需要 设计 含有继承关系的几个类。如果这个功能出现在采用了 SSM 框架的 JavaEE项目中，那么，这个继承关系该设计到哪里呢？
