Plain Old Java Object（POJO））という用語の正確な意味は何ですか？
用語Plain Old Java Object（POJO））はどういう意味ですか？十分な説明が見つかりませんでした。
POJOのWikipediaページ は、POJOは通常のJavaオブジェクトであり、特別なオブジェクトではないことを示しています。
また、上記のページでは、POJOは事前に指定されたクラスを拡張したり、事前に指定されたインターフェイスを実装したり、事前に指定された注釈を含める必要はありません。それはまた、POJOがSerializable、Comparableなどのインターフェース、またはアプレットやその他のユーザー作成のクラス/インターフェースなどのクラスを実装できないことを意味しますか？
また、上記のポリシー（拡張なし、実装なし）は、外部ライブラリの使用が許可されていないことを意味しますか？
POJOは正確にどこで使用されますか？
EDIT：具体的には、Javaの一部であるクラス/インターフェースを拡張/実装することができますか？または外部ライブラリはありますか？
プレーンオールドJava Object この名前は、特定のオブジェクトが通常のJavaオブジェクトであり、EJB 2フレームワークで定義されているような特別なオブジェクトではないことを強調するために使用されます。
クラスA {}
クラスBはCを拡張/実装します{}
注：Cが分散フレームワーククラスまたはifcの一種である場合、Bは非POJOです。例えばjavax.servlet.http.HttpServlet、javax.ejb.EntityBeanまたはJ2EE extnであり、シリアライズ可能/比較可能ではありません。シリアル化可能/比較可能はPOJOに有効です。
ここで、Aは独立した単純なオブジェクトです。 BはCを拡張/実装しているため、Bは特別なオブジェクトです。したがって、BオブジェクトはCからより多くの意味を取得し、BはCからの規則に従うことを制限します。 固く結ばれた 分散フレームワークで。したがって、Bオブジェクトはその定義からはPOJOではありません。
クラスAオブジェクト参照を使用するコードは、そのタイプについて何も知る必要がなく、多くのフレームワークで使用できます。
したがって、POJOは1）事前に指定されたクラスを拡張し、2）事前に指定されたインターフェイスを実装する必要はありません。
JavaBeanはPOJOの例であり、シリアライズ可能であり、引数のないコンストラクターを持ち、単純な命名規則に従うゲッターメソッドとセッターメソッドを使用してプロパティにアクセスできます。
POJOは純粋にビジネスロジックに焦点を当てており、（エンタープライズ）フレームワークに依存しません。ビジネスロジックのコードはあるが、このインスタンスの作成方法、このオブジェクトが属するサービス（EJB ..）、およびその特別な特性（ステートフル/ステートレス）はフレームワークによって外部xmlを使用して決定されることを意味します。ファイル。
例1：JAXBは、JavaオブジェクトをXMLとして表現するサービスです。これらのJavaオブジェクトは単純で、デフォルトのコンストラクターgetterおよびsetterを作成します。
例2：単純なJavaクラスを使用してテーブルを表すHibernate。列はそのインスタンスになります。
例3：REST services。REST=サービスでは、DB上でいくつかの操作を実行するためのサービス層とDao層があります。したがって、Daoはベンダー固有のクエリとサービス層は、どのDAO層を呼び出してDB操作を実行します。DAOのAPI（メソッド）の作成または更新は、POJOを引数として受け取り、そのPOJOを更新し、DBに挿入/更新します。これらのPOJO（Javaクラス）は、各列とそのゲッターとセッターの状態（インスタンス変数）のみを持ちます。
実際には、注釈が洗練されていると感じる人もいれば、XMLを冗長でくて保守が難しいと考える人もいれば、注釈がPOJOモデルを汚染する人もいます。したがって、XMLの代替として、多くのフレームワーク（Spring、EJB、JPAなど）では、XMLの代わりに、またはXMLに加えて注釈を使用できます。
利点：
インフラストラクチャフレームワークからアプリケーションコードを分離することは、POJOを使用する多くの利点の1つです。 POJOを使用すると、常に変化する揮発性のインフラストラクチャフレームワークから切り離され、アプリケーションのビジネスロジックが将来にわたって保証されます。新しいバージョンにアップグレードするか、別のフレームワークに切り替えると、より簡単でリスクが少なくなります。また、POJOを使用するとテストが容易になり、開発が簡素化されて加速されます。インフラストラクチャコードに絡まないため、ビジネスロジックがより明確でシンプルになります。
Martin Fowlerによる 、彼と他の何人かは、EJBなどとは対照的に標準クラスである何かを記述する方法としてそれを思いついた。
この用語の使用は、それがあなたに伝えることになっていることを意味します。たとえば、依存性注入フレームワークが、他のPOJOにPOJOを注入できることを通知する場合、特別なことは何もする必要がないと言います。オブジェクトとの契約に従う必要はなく、インターフェースを実装しますまたは特別なクラスを拡張します。既に持っているものなら何でも使用できます。
[〜＃〜] update [〜＃〜]別の例を挙げると：Hibernateは任意のPOJO（作成したオブジェクト）をコアデータ（iPhoneのObjective C）のSQLテーブルにマッピングできます。システムがデータベースに永続化できるようにするには、オブジェクトはNSManagedObjectを拡張する必要があります。その意味で、Hibernateは可能ですが、Core DataはPOJO（またはPOOCO = PlainOldObjectiveCObject）と連携できません。 （コアデータを拾い始めたばかりなので、コアデータを100％正確に修正できない可能性があります。ヒントや修正は歓迎します:-)）。
プレーンオールドJava Object :)
さて、それらはすべてひどい制限であるように聞こえます。
POJOが使用される通常のコンテキストでは、それはより多くの利点に似ています：
これは、使用しているライブラリ/ APIが、Javaなんらかの方法で修正または操作されていないオブジェクト、つまり、何もする必要のないオブジェクトを完全に処理できることを意味します。それらを機能させるために特別です。
たとえば、XStream XMLプロセッサは（と思う）幸運にもJava Serializableインターフェイスを実装しないクラスをシリアル化します。それはプラスです！データオブジェクトで動作する多くの製品SomeProprietaryDataObjectの実装を強制したり、AbstractProprietaryDataObjectクラスを拡張したりするために使用されます。
通常、POJOで動作するものはすべて、そうでないPO-JOでも動作します。そのため、XStreamはもちろんSerializableクラスもシリアル化します。
POJOは、Plain Old Java Object-Enterprise Edition（J2EE）のもの（beansなど）を必要とするものと比較して）です。
POJOは実際には難しくて高速な定義ではなく、「通常の」非エンタープライズJavaオブジェクト。外部ライブラリまたはフレームワークを使用してオブジェクトを作成する場合、 POJOかどうかは、主にWHATライブラリ/フレームワークに依存しますが、フレームワークがPOJOのようなものをより少なくすることになると思います
POJOの重要なポイントは単純さであり、見た目よりも複雑なものを想定しているように見えます。
ライブラリがPOJOをサポートしている場合、任意のクラスのオブジェクトが受け入れ可能であることを意味します。それは、POJOが注釈/インターフェースを持つことができない、またはそれらが存在する場合に使用されないという意味ではありませんが、それは要件ではありません。
私見wikiページはかなり明確です。 POJOが注釈/インターフェースを持つことができないとは言っていません。
用語Plain Old Java Object（POJO）はどういう意味ですか？
[〜＃〜] pojo [〜＃〜]は、2000年9月の会議での講演の準備をしていたとき、Martin Fowler、Rebecca Parsons、およびJosh Mackenzieによって造られました。MartinFowler in エンタープライズアプリケーションアーキテクチャのパターン Javaでドメインモデルパターンを実装する方法を説明しています。 EJB Entity Beansを使用することの欠点のいくつかを列挙した後：
J2EEでドメインモデルを開発することについて話すとき、常に多くの熱が発生します。教材やJ2EE入門書の多くは、エンティティBeanを使用してドメインモデルを開発することを推奨していますが、少なくとも現在の（2.0）仕様では、このアプローチには重大な問題があります。
エンティティBeanは、コンテナ管理による永続性（CMP）を使用する場合に最も役立ちます...
エンティティBeanは再入できません。つまり、あるエンティティBeanから別のオブジェクトに呼び出すと、その別のオブジェクト（またはそれが呼び出すオブジェクト）は最初のエンティティBeanにコールバックできません...
...きめ細かいインターフェイスを持つリモートオブジェクトがある場合、ひどいパフォーマンスが得られます...
エンティティBeanで実行するには、コンテナとデータベースが接続されている必要があります。これにより、ビルド時間が長くなり、テストはデータベースに対して実行する必要があるため、テスト実行の時間も長くなります。エンティティBeanもデバッグが困難です。
別の方法として、彼はRegular Java Objectsをドメインモデルの実装に使用することを提案しました。
別の方法として、通常のJavaオブジェクトを使用しますが、これはしばしば驚く反応を引き起こします。通常のJavaオブジェクトを実行できないと考える人が多いのは驚くべきことですEJBコンテナ内私は、人々は普通のJavaオブジェクトは空想的な名前を持っていないので、忘れているという結論に達しました。だからこそ、 2000年の講演の準備中に、Rebecca Parsons、Josh Mackenzie、私は彼らに次の1つを与えました：POJO（plain old Java objects）。POJOドメインモデルまとめやすく、ビルドが速く、EJBコンテナの外部で実行およびテストでき、EJBから独立しています（そのため、EJBベンダーは使用を推奨していません）。
拡張のすべてのビジネスロジックを含むプレーンオールドJavaオブジェクト（POJO））。
Exp。単一のメソッドを含むPojo
public class Extension {
public static void logInfo(String message) {
System.out.println(message);
}
}