71

Plain Old Java Object (POJO)という用語は何を意味しますか? 十分に説明できるものは見つかりませんでした。

POJO のウィキペディア ページには、POJO は通常の Java オブジェクトであり、特別なオブジェクトではないことが記載されています。では、Java でオブジェクトを特別にするものとしないものは何でしょうか?

上記のページでは、POJO は事前に指定されたクラスを拡張したり、事前に指定されたインターフェイスを実装したり、事前に指定された注釈を含めたりする必要はないと述べています。これは、POJO がのようなインターフェースや、アプレットのようなクラスSerializable、Comparableまたはその他のユーザー作成のクラス/インターフェースを実装することを許可されていないということでもありますか?

また、上記のポリシー (拡張なし、実装なし) は、外部ライブラリの使用が許可されていないことを意味しますか?

POJO は正確にはどこで使用されますか?

編集:より具体的に言うと、Java または外部ライブラリの一部であるクラス/インターフェースを拡張/実装することは許可されていますか?

4

9 に答える 9

58

プレーンオールドJavaオブジェクトこの名前は、特定のオブジェクトが通常のJavaオブジェクトであり、EJB2フレームワークで定義されているような特別なオブジェクトではないことを強調するために使用されます。

クラス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は分散フレームワークと緊密に結合されます。したがって、Bオブジェクトはその定義からPOJOではありません。

クラスを使用するコードオブジェクト参照は、そのタイプについて何も知る必要がなく、多くのフレームワークで使用できます。

したがって、POJOは、1）事前に指定されたクラスを拡張し、2）事前に指定されたインターフェースを実装する必要はありません。

JavaBeanは、シリアライズ可能で、引数のないコンストラクターを持ち、単純な命名規則に従うgetterメソッドとsetterメソッドを使用してプロパティにアクセスできるPOJOの例です。

POJOは純粋にビジネスロジックに焦点を合わせており、（エンタープライズ）フレームワークに依存していません。これは、ビジネスロジックのコードがあることを意味しますが、このインスタンスの作成方法、このオブジェクトが属するサービス（EJB ..）、およびその特殊な特性（ステートフル/ステートレス）は、外部xmlを使用してフレームワークによって決定されます。ファイル。

例1：JAXBは、JavaオブジェクトをXMLとして表すサービスです。これらのJavaオブジェクトは単純で、デフォルトのコンストラクターゲッターとセッターがあります。

例2：テーブルを表すために単純なJavaクラスが使用されるHibernate。列がそのインスタンスになります。

例3：RESTサービス。RESTサービスでは、DB上でいくつかの操作を実行するためのサービスレイヤーとDaoレイヤーがあります。したがって、Daoにはベンダー固有のクエリと操作があります。サービスレイヤーは、DB操作を実行するためにどのDAOレイヤーを呼び出すかを担当します。DAOのAPI（メソッド）の作成または更新は、POJOを引数として取り、そのPOJOを更新し、DBに挿入/更新します。これらのPOJO（Javaクラス）には、各列とそのゲッターおよびセッターの状態（インスタンス変数）のみが含まれます。

実際には、注釈がエレガントであると感じる人もいれば、XMLを冗長で醜く、維持するのが難しいと考える人もいますが、注釈がPOJOモデルを汚染していると感じる人もいます。したがって、XMLの代わりに、多くのフレームワーク（Spring、EJB、JPAなど）では、XMLの代わりに、またはXMLに加えて注釈を使用できます。

利点：
アプリケーションコードをインフラストラクチャフレームワークから切り離すことは、POJOを使用する多くの利点の1つです。POJOを使用すると、アプリケーションのビジネスロジックを、不安定で絶えず進化するインフラストラクチャフレームワークから切り離すことで、将来にわたって利用できるようになります。新しいバージョンへのアップグレードや別のフレームワークへの切り替えが簡単になり、リスクが軽減されます。POJOを使用すると、テストも簡単になり、開発が簡素化および加速されます。インフラストラクチャコードと絡まないため、ビジネスロジックがより明確でシンプルになります

参照：wiki source2

于 2012-10-03T18:27:33.303 に答える
10

Martin Fowlerによると、彼と他の何人かは、EJBなどではなく標準クラスである何かを記述する方法としてそれを思いついた。

于 2010-07-24T18:37:58.060 に答える
7

この用語の使用は、それがあなたに言うことになっていることを意味します。たとえば、依存性注入フレームワークが、POJOを他のPOJOに注入できると言った場合、特別なことは何もする必要はないと言いたいのです。オブジェクトとのコントラクトに従う必要はなく、インターフェイスを実装します。または特別なクラスを拡張します。すでに持っているものなら何でも使えます。

更新別の例を挙げると、Hibernateは任意のPOJO（作成したオブジェクト）をSQLテーブルにマップできますが、Core Data（iPhoneのObjective C）では、システムがオブジェクトを永続化できるように、オブジェクトをNSManagedObjectに拡張する必要があります。データベース。その意味で、コアデータはPOJO（またはPOOCO = PlainOldObjectiveCObject）では機能しませんが、Hibernateでは機能します。（コアデータを取得し始めたばかりなので、100％正確ではない可能性があります。ヒント/修正は大歓迎です:-)）。

于 2010-07-24T18:37:42.897 に答える
6

プレーンな古い Java オブジェクト :)

ええと、あなたはそれらがすべてひどい制限であるように聞こえます.

POJO が使用されている通常のコンテキストでは、利点のようなものです。

これは、使用しているライブラリ/API が、何らかの方法で改ざんされていない、または操作されていない Java オブジェクトを完全に処理することを意味します。つまり、それらを機能させるために特別なことをする必要はありません。

たとえば、XStream XML プロセッサは (私が思うに)Serializableインターフェースを実装していない Java クラスを喜んでシリアライズします。それはプラスです！データ オブジェクトを扱う多くの製品は、クラスの実装SomeProprietaryDataObjectや拡張を強制するために使用されていました。AbstractProprietaryDataObject多くのライブラリは、Bean の動作、つまり getter と setter を想定しています。

通常、POJO で機能するものは、そうではない PO-JO でも機能します。したがって、XStream はもちろんシリアライズ可能なクラスもシリアライズします。

于 2010-07-24T18:32:33.297 に答える
5

POJO はプレーン オールド Java オブジェクトです。エンタープライズ エディション (J2EE) のもの (Bean など) を必要とするものとは対照的です。

POJO は実際には厳格な定義ではなく、「通常の」非エンタープライズ Java オブジェクトを説明するためのより巧妙な方法です。外部ライブラリまたはフレームワークを使用してオブジェクトを POJO にするかどうかは、主にどのライブラリ/フレームワークに依存するかによって、一種の見る人の目にかかっていますが、私はフレームワークが POJO の何かをより少なくすると思います。

于 2010-07-24T18:37:20.840 に答える
3

POJO の全体的なポイントは単純さであり、見た目よりも複雑なものを想定しているように見えます。

ライブラリが POJO をサポートしている場合は、任意のクラスのオブジェクトが受け入れられることを意味します。これは、POJO がアノテーション/インターフェースを持つことができない、または存在しても使用されないという意味ではありませんが、必須ではありません。

IMHO wikiページはかなり明確です。POJO が注釈/インターフェースを持つことができないとは言いません。

于 2010-07-28T06:54:38.553 に答える
1

半分正しくて半分間違っている投稿がたくさんあります。正しい解釈の最良の例は、Rex M の回答 here にあります。

[POJOはクラスです]それを機能させるために重要な「根性」を必要としません。この考え方は、独自にインスタンス化して操作するのが難しい (またはできない) 非常に依存性の高いオブジェクトとは対照的です。これらのオブジェクトは、他のサービス、ドライバー、プロバイダー インスタンスなども存在する必要があります。

残念なことに、これらのまったく同じ答えは、しばしば、それらが何らかの形で単純である、またはしばしば単純な構造を持っているという誤解を伴います. これは必ずしも真実ではなく、混乱は、Java (POJO) および C# の世界 (POCO) のビジネス ロジックが、特に Web アプリケーションの世界で比較的簡単にモデル化されるという事実から生じているようです。

POJO は、複数レベルの継承、ジェネリック型、抽象化などを持つことができます。これは、ビジネス ロジックで必要とされないため、大部分の Web アプリケーションでは必要とされないのがたまたまです。データベース、クエリ、データ転送オブジェクトとリポジトリ。

単純な Web アプリケーションから脱線するとすぐに、POJO はより複雑に見え始めます。たとえば、タクシーをユーザーのスケジュールに割り当てる Web アプリを作成します。これを行うには、グラフの色付けアルゴリズムが必要です。グラフに色を付けるには、グラフ オブジェクトが必要です。グラフの各ノードはスケジュール オブジェクトです。グラフの色付けをスケジュールだけでなく他のことでもできるように、汎用的にしたい場合はどうでしょうか。ジェネリック、アブストラクト、継承のレベルを追加することができます - ほとんどミニライブラリにするところまでです。

ただし、この時点では、その複雑さに関係なく、他のフレームワークの内臓に依存していないため、POJO のままです。

于 2021-12-17T20:59:54.447 に答える
1

Plain Old Java Object (POJO) という用語は何を意味しますか?

POJOは、Martin Fowler、Rebecca Parsons、および Josh Mackenzie が 2000 年 9 月の会議で講演の準備をしていたときに造語されました。Martin Fowler は、エンタープライズ アプリケーション アーキテクチャのパターンで、Java でドメイン モデルパターンを実装する方法を説明しています。EJB エンティティ Beanを使用することのいくつかの欠点を列挙した後:

J2EE でのドメイン モデルの開発について人々が話すと、常に多くの熱が発生します。教材や J2EE の入門書の多くは、エンティティ Bean を使用してドメイン モデルを開発することを提案していますが、少なくとも現在の (2.0) 仕様では、このアプローチには深刻な問題がいくつかあります。

エンティティ Bean は、Container Managed Persistence (CMP) を使用する場合に最も役立ちます...

エンティティ Bean は再入可能にできません。つまり、あるエンティティ Bean から別のオブジェクトを呼び出した場合、その他のオブジェクト (またはそれが呼び出すオブジェクト) は最初のエンティティ Bean にコールバックできません...

...きめの細かいインターフェースを備えたリモートオブジェクトがある場合、ひどいパフォーマンスが得られます...

エンティティ Bean で実行するには、コンテナーとデータベースが接続されている必要があります。これにより、ビルド時間が長くなり、テストをデータベースに対して実行する必要があるため、テスト実行の時間も長くなります。エンティティ Bean もデバッグが難しいです。

別の方法として、彼はドメイン モデルの実装に通常の Java オブジェクトを使用することを提案しました。

別の方法として、通常の Java オブジェクトを使用することもできますが、通常の Java オブジェクトは EJB コンテナーでは実行できないと考えている人が驚くほど多いのですが、これには驚くべき反応が生じることがよくあります。通常の Java オブジェクトには派手な名前がないため、人々は通常の Java オブジェクトを忘れているという結論に達しました。そのため、2000 年の講演の準備中に、Rebecca Parsons、Josh Mackenzie、および私が彼らに POJO (plain old Java objects) を提供しました。POJO ドメイン モデルは、組み立てが簡単で、構築が速く、EJB コンテナーの外部で実行およびテストでき、EJB から独立しています (これが、EJB ベンダーがそれらの使用を推奨しない理由かもしれません)。

于 2016-04-01T12:30:33.327 に答える
0

拡張機能のすべてのビジネス ロジックを含む Plain Old Java Object (POJO)。

経験値 単一のメソッドを含む Pojo

public class Extension {
   public static void logInfo(String message) {
      System.out.println(message);
   }
}
于 2013-09-17T09:52:15.253 に答える