Plain_old_Java_object
ソフトウェアエンジニアリングでは、プレーンオールド Java オブジェクト( POJO ) は、特別な制限に束縛されない通常のJava オブジェクトです。この用語は、 2000 年 9 月にマーティン ファウラー、レベッカ パーソンズ、ジョシュ マッケンジーによって造られました。
「私たちは、なぜ人々が自分たちのシステムで通常のオブジェクトを使用することにそれほど反対するのか疑問に思い、それは単純なオブジェクトには派手な名前がないためであると結論付けました。そこで、私たちは彼らに名前を付けました。そして、それは非常にうまく普及しています。」
「POJO」という用語は当初、主要な Java オブジェクト モデル、規約、またはフレームワークのいずれにも従わない Java オブジェクトを指しました。最近では、「POJO」は、単純な古い JavaScript オブジェクトの頭字語としても使用されることがこの場合、この用語は、同様の系譜を持つJavaScriptオブジェクトを指します。
この用語は、派手な新機能を使用しないテクノロジーのレトロニムを造る頭字語パターンを継続しています。つまり、 RubyのPlain Old Ruby Object (PORO) 、電話のPlain Old Telephone Service (POTS) 、PerlのPlain Old Documentation (pod) です。.NET Frameworkの POJO に相当するのは、Plain Old CLR オブジェクト(POCO)です。 PHPの場合、これは単純な古い PHP オブジェクト(POPO)です。
POJO 現象が広く受け入れられたのは、複雑なオブジェクト フレームワークとは対照的な、共通で理解しやすい用語が必要なためと考えられます。
コンテンツ
1 意味
2 状況に応じたバリエーション
2.1 JavaBeans 2.2 透過的にサービスを追加する 3.1 シンプルな古い Java インターフェイス
4 こちらも参照
5 参考文献
意味
理想的に言えば、POJO は Java 言語仕様によって強制される制限以外の制限に束縛されない Java オブジェクトです。つまり、POJO は次のようにする必要はありません。
次のように、事前に指定されたクラスを拡張します。
public class Foo はjavaxを拡張します。サーブレット。http 。Httpサーブレット{ …
次のように、事前に指定されたインターフェイスを実装します。
パブリッククラスBar はjavaxを実装します。ejb 。EntityBean { …
次のように、
事前に指定された注釈を含めます。
@javax.persistence.Entity public class Baz { …
ただし、技術的な問題やその他の理由により、POJO 準拠として説明されている多くのソフトウェア製品やフレームワークは、実際には依然として適切に動作するために永続化などの機能について事前に指定されたアノテーションを使用する必要が注釈が追加される前にオブジェクト (実際にはクラス) が POJO であり、注釈が削除されると POJO ステータスに戻る場合でも、それは引き続き POJO であると見なせるという考えです。この場合、基本オブジェクトは、「特殊化された Java オブジェクト」 (SJO または (原文どおり) SoJO) となる特別な特性 (実装されたインターフェイスなど) を持たないため、POJO のままになります。
状況に応じたバリエーション編集
JavaBeans
JavaBean はシリアル化可能で、引数のないコンストラクターを持ち、単純な命名規則に従うgetter メソッドと setter メソッドを使用してプロパティにアクセスできるPOJO です。この規則により、任意の JavaBeans のプロパティに対して単純な宣言参照を行うことができます。このような宣言的参照を使用するコードは、Bean の型について何も知る必要がなく、Bean は多くのフレームワークで使用でき、フレームワークが Bean の正確な型を知る必要はありません。JavaBeans 仕様は、完全に実装されている場合、クラスが真の JavaBean になるためにSerializableインターフェイスを実装する必要があるため、POJO モデルをわずかに壊します。JavaBeans と呼ばれる多くの POJO クラスは、この要件を満たしSerializable はマーカー (メソッドレス) インターフェイスであるため、これはそれほど負担ではありません。
以下に、POJO のプロパティへの双方向バインディングを持つJavaServer Faces (JSF) コンポーネントの例を示します。
POJO の定義は次のようになります。
パブリッククラスMyBean {
プライベート文字列someProperty ;
public String getSomeProperty () { return someProperty ; }
public void setSomeProperty ( String someProperty ) { this . someProperty = someProperty ; } }
JavaBean の命名規則により、単一の「someProperty」参照は、値を取得するための「getSomeProperty()」(プロパティがブール型の場合は「isSomeProperty()」) メソッドと、「setSomeProperty()」メソッドに自動的に変換できます。 String)」メソッドを使用して値を設定します。
透過的にサービスを追加する
POJO を使用した設計がより一般的に使用されるようになるにつれて、フレームワークで使用されるすべての機能を POJO に提供し、実際に必要な機能領域についてより多くの選択肢を提供するシステムが登場しました。このモデルでは、プログラマは POJO のみを作成します。この POJO は純粋にビジネス ロジックに焦点を当てており、(エンタープライズ) フレームワークには依存しません。アスペクト指向プログラミング(AOP) フレームワークは、永続性、トランザクション、セキュリティなどの横断的な懸念事項を透過的に追加します。
Spring はこのアイデアを初期に実装したものであり、このモデルを普及させる原動力の 1 つでした。
POJO である EJB Bean の例:
エンタープライズ JavaBeans (EJB)、
Java Persistence API (JPA) ( Hibernateを含む)
CDI (Java EE プラットフォームのコンテキストと依存関係の注入)
以下に完全に機能する EJB Bean を示し、EJB3 が POJO モデルをどのように利用するかを示しています。
パブリッククラスHelloWorldService {
public String SayHello () { return “こんにちは、世界!” ; } }
前述のとおり、Bean は EJB クラスを拡張したり、EJB インターフェイスを実装したりする必要はなく、また EJB アノテーションを含める必要もありません。代わりに、プログラマは、どの EJB サービスを Bean に追加する必要があるかを外部XMLファイルで宣言します。
実際には、注釈が洗練されていると感じる人もいれば、XML は冗長で醜く、保守が難しいと考える人もいます。また、注釈が POJO モデルを汚していると考える人もいます。
したがって、XML の代替として、多くのフレームワーク (Spring、EJB、JPA など) では、XML の代わりに、または XML に加えて、アノテーションを使用できます。以下は、上記と同じ EJB Bean を示していますが、注釈が追加されています。この場合、XML ファイルは必要なくなります。
@Stateless public class HelloWorldService {
public String SayHello () { return “こんにちは、世界!” ; } }
上記のようなアノテーションを使用すると、Bean は真に純粋な POJO ではなくなりますが、アノテーションは単なる受動的なメタデータであるため、クラスを拡張したりインターフェイスを実装したりする必要がある侵襲性に比べて、有害な欠点ははるかに少なくなります。したがって、プログラミング モデルは依然として純粋な POJO モデルに非常によく似ています。
関連する頭字語
シンプルな古い Java インターフェイス
Plain old Java Interface (POJI) はJava インターフェイスの基本形式であり、より複雑な Java インターフェイスが許可されない場合に受け入れられます。 : 57、572、576、579、1340
こちらも参照
データ転送オブジェクト(DTO)
貧血ドメインモデル
KISSの原則
参考文献
^ “MF ブリキ: POJO” . マーティンファウラー.com。
^ アルマー、ディオン （2006-07-17)。「POJO の復活: プレーンな ‘Ole JavaScript」。アジャシアン。2014 年 9 月 13 日にオリジナルからアーカイブされました。2014 年 8 月 19 日に取得。
^ “ポコサポート” . マイクロソフト.com 。2012 年 5 月 27 日に取得。
^ クネシュケ、ヤン （2007-02-19)。「PHP のタイプセーフ オブジェクト」。クネシュケ.デ。2012 年 3 月 26 日にオリジナルからアーカイブされました。2012 年 5 月 27 日に取得。
^ チョン、ジム （2011-06-26). 「必要最小限の Plain Old PHP オブジェクト、別名 POPO を備えたコントローラー」。jym.sg。2012 年 3 月 26 日にオリジナルからアーカイブされました。2012 年 5 月 27 日に取得。
^ マーティン、ロバート C; （2008); クリーン コード、第 11 章、Pure Java AOP フレームワーク ^ パンダ、デブ; ラーマン、レザー。レーン、デレク。（2007)。EJB 3 in action、Manning Publications Co.、シェルターアイランド（ニューヨーク州）、
ISBN 978-1-93-398834-4 (www.manning.com/books/ejb-3-in-action)。第 11 章、デプロイメント記述子とアノテーション ^ ワーリ、ウエリ; ビエイラ、ミゲル。ゴメス、フェレイラ・ロペス。ヘイニー、ブライアン。モハッラム、アハメッド。ナポリ、ファンパブロ。ロール、マルコ。キュイ、ヘンリー。ガン、パトリック。ゴンザレス、セルソ。ウグルル、ピナール。ジオシ、ララ（2009年6月29日）。Rational Application Developer V7.5 プログラミング ガイド。IBM レッドブック。ISBN 978-0738432892。