简单的老Java对象（POJO）这个术语究竟意味着什么？
简单老Java对象（POJO）是什么意思？ 我找不到任何足够的解释。
POJO的维基百科页面说，POJO是一个普通的Java对象，而不是一个特殊的对象。 现在，是什么使得Java中没有什么特别的对象？
上面的页面还说，POJO不应该扩展预先指定的类，实现预先指定的接口或包含预先指定的注释。 这是否也意味着POJO不允许实现像Serializable ， Comparable或Applets之类的接口或者任何其他用户编写的类/接口？
另外，上述政策（不延伸，不实施）是否意味着我们不被允许使用任何外部图书馆？
在哪里使用POJO？
编辑：更具体地说，我允许扩展/实现是Java或任何外部库的一部分的类/接口？
普通Java对象名称用于强调给定的对象是一个普通的Java对象，而不是像EJB 2框架定义的那样的特殊对象。
class A {}
B类扩展/实现C {}
注意：当C是一种分布式框架类或ifc时，B不是POJO。 例如javax.servlet.http.HttpServlet，javax.ejb.EntityBean或J2EE extn，而不是可序列化/可比较的。 由于可序列化/可比较对于POJO是有效的。
这里A是简单的对象，是独立的。 B是一个特殊的obj，因为B扩展/实现了C，所以B对象从C得到更多的意义，B限制遵循C的规则，B与分布式框架紧密结合 。 因此B对象并不是POJO的定义。
使用类的代码一个对象引用不必知道它的types，它可以用于许多框架。
所以POJO不应该1）扩展预先指定的类，2）实现预先指定的接口。
JavaBean是一个可序列化的POJO的例子，它有一个无参数的构造函数，并允许使用遵循简单命名约定的getter和setter方法来访问属性。
POJO完全专注于业务逻辑，并且不依赖于（企业）框架。 这意味着它具有业务逻辑的代码，但是如何创build这个实例，这个对象属于哪个服务（EJB ..）以及它的特殊特性（有状态/无状态）将由框架通过使用外部XML来决定文件。
例1：JAXB是将java对象表示为XML的服务; 这些java对象很简单，并且提供了默认的构造函数getter和setter。
例2：Hibernate将使用简单的java类来表示一个表。 列将是它的实例。
示例3：REST服务。 在REST服务中，我们将使用服务层和Dao层对数据库执行一些操作。 所以道将有供应商特定的查询和操作。 服务层将负责调用哪个DAO层来执行数据库操作。 创build或更新DAO的API（方法）将以POJO作为参数，并更新该POJO并插入/更新到DB中。 这些POJO（Java类）将只有每个列的状态（实例variables）以及它的getter和setter。
在实践中，有些人发现注释是优雅的，而他们认为XML是冗长，丑陋和难以维护的，而另外一些人则发现注释污染了POJO模型。 因此，作为XML的替代scheme，许多框架（例如Spring，EJB和JPA）允许使用注释来代替或除了XML：
优点：
将应用程序代码与基础架构框架分离是使用POJO的诸多好处之一。 使用POJO可以将应用程序的业务逻辑从不稳定，不断发展的基础架构中分离出来，从而certificate您的应用程序的业务逻辑。 升级到新版本或切换到不同的框架变得更容易，风险更小。 POJO也使testing更容易，简化和加速发展。 您的业务逻辑将变得更加清晰和简单，因为它不会与基础架构代码纠缠在一起
参考文献： wiki source2
根据Martin Fowler的说法 ，他和其他一些人想出了一个方法来描述一个标准的类，而不是EJB。
这个词的用法暗示着它应该告诉你什么。 例如，如果一个dependency injection框架告诉你可以将一个POJO注入到任何其他的POJO中，他们可以说你不需要做任何特殊的事情：不需要遵守与你的对象的任何契约，实现任何接口或延长特殊class级。 你可以使用你已经有的东西。
更新要举另一个例子：虽然Hibernate可以将任何POJO（您创build的任何对象）映射到SQL表，但在核心数据（iPhone上的Objective C）中，对象必须扩展NSManagedObject，以便系统能够将它们一个数据库。 从这个意义上说，核心数据不能与任何POJO（或者说POOCO = PlainOldObjectiveCObject）一起使用，而Hibernate可以。 （我可能不会100％正确的重新核心数据，因为我刚开始拿起它，任何提示/更正，欢迎:-)）。
简单的旧Java对象:)
那么，你听起来像这些都是可怕的限制。
在使用POJO的通常情况下，这更像是一个好处：
这意味着无论您使用的库/ API是否完全愿意使用未经过任何处理或手动处理的Java对象，也就是说，您无需执行任何特殊的操作即可使其工作。
例如，XStream XML处理器（我认为）会愉快地序列化没有实现Serializable接口的Java类。 这是一个加号！ 许多使用数据对象的产品用于强制实施SomeProprietaryDataObject ，甚至扩展AbstractProprietaryDataObject类。 许多库将期望bean行为，即getter和setter。
通常，任何与POJO一起工作的人也可以使用不PO-JO的工作。 所以XStream当然也会序列化Serializable类。
POJO是一个简单的旧Java对象 – 相比，需要企业版（J2EE）的东西（豆等…）。
POJO实际上并不是一个硬性的定义，更多的是描述“正常”的非企业Java对象的手工方式。 无论是使用外部库还是框架都会使对象POJO成为仁者见仁的对象，在很大程度上取决于WHAT的库/框架，尽pipe我敢于猜测一个框架会使得POJO更less
一个POJO的整个观点是简单的，你似乎正在假设比看起来更复杂的东西。
如果一个库支持一个POJO，它意味着任何一个类的对象都是可接受的。 这并不意味着POJO不能有注释/接口，或者如果它们在那里，它们将不会被使用，但这不是必需的。
恕我直言维基页面是相当清楚的。 它并没有说POJO不能有注释/接口。
一个简单的旧Java对象（POJO），包含您的扩展的所有业务逻辑。
进出口。 包含单一方法的Pojo
public class Extension { public static void logInfo(String message) { System.out.println(message); } }
简单老Java对象（POJO）是什么意思？
POJO由Martin Fowler，Rebecca Parsons和Josh Mackenzie在2000年9月的会议上准备发表演讲时创造。Martin Fowler在企业应用程序体系结构模式中解释了如何在Java中实现领域模型模式。 列举了使用EJB Entity Beans的一些缺点之后：
当人们谈论在J2EE中开发一个领域模型时总会产生很多热量。 许多教材和介绍性的J2EE书籍build议您使用实体bean来开发一个领域模型，但是这种方法存在一些严重的问题，至less在当前的（2.0）规范中是这样。
当您使用容器pipe理持久性（CMP）时，实体bean是最有用的…
实体bean不能重入。 也就是说，如果您从一个实体bean调用另一个对象，则该另一个对象（或其调用的任何对象）将无法callback到第一个实体bean中。
…如果你有远程对象细粒度的界面，你会得到糟糕的performance…
要运行实体bean，您需要连接一个容器和一个数据库。 由于testing必须针对数据库执行，因此这会增加构build时间并增加testing运行的时间。 实体bean也很难debugging。
作为一种select，他build议使用Regular Java Objects for Domain Model实现：
另一种方法是使用普通的Java对象，虽然这经常引起一个惊讶的反应 – 令人惊讶的是有多less人认为你不能在EJB容器中运行普通的Java对象。 我得出的结论是，人们忘了普通的Java对象，因为他们没有一个奇特的名字。 这就是为什么在2000年准备讲话的时候，丽贝卡·帕森斯（Rebecca Parsons），乔什·麦肯齐（Josh Mackenzie）和我给了他们一个：POJO（普通的旧Java对象） 。 POJO领域模型很容易放在一起，快速构build，可以在EJB容器之外运行和testing，并且独立于EJB（也许这就是为什么EJB供应商不鼓励您使用它们）。
