昔ながらのJavaオブジェクト

ソフトウェア工学において、プレーンオールドJavaオブジェクト（POJO）は、特別な制限に縛られない通常のJava オブジェクトです。この用語は、2000年9月にマーティン・ファウラー、レベッカ・パーソンズ、ジョシュ・マッケンジーによって造られました。 ^[1]

「なぜ人々がシステム内で通常のオブジェクトを使用することにそれほど反対するのか疑問に思い、単純なオブジェクトには派手な名前がないからだと結論付けました。そこで私たちはオブジェクトに派手な名前を付けました。そしてそれはとてもうまく受け入れられました。」^[1]

「POJO」という用語は当初、主要な Java オブジェクト モデル、規則、フレームワークのいずれにも従わない Java オブジェクトを意味していました。その後、複雑なオブジェクト フレームワークとは対照的な、共通で理解しやすい用語の必要性から、言語に依存しない用語として採用されるようになりました。^{[引用が必要]}

この用語は、新しい派手な機能を使用しない構造を 表すレトロニムを作り出すために、頭字語のパターンを継続しています。

• JavaScriptにおける「単純な古いJavaScriptオブジェクト」^[2]
• Rubyの「Plain old Ruby object」(PORO)
• Perlの「昔ながらのドキュメント」(pod)
• .NET FrameworkのPlain Old CLRオブジェクト（POCO）^[3]
• PHPにおける「プレーンオールドPHPオブジェクト」（POPO）^{[4] [5]}
• 電話における一般電話サービス(POTS)

理想的には、POJOはJava言語仕様によって強制されるもの以外のいかなる制約にも縛られないJavaオブジェクトです。つまり、POJO は

1. 次のように、事前に指定されたクラスを拡張します。

   パブリッククラスFooはjavax.servlet.http.HttpServletを拡張します{ ...​​      
   

2. 以下のように、事前に指定されたインターフェースを実装する。

   パブリッククラスBar はjavax.ejb.EntityBean { ...を実装します。      
   

3. 以下のように、事前に指定された注釈を含む

   @javax.persistence.EntityパブリッククラスBaz { ...     
   

しかし、技術的な困難やその他の理由により、POJO 準拠と説明されている多くのソフトウェア製品やフレームワークでは、永続性などの機能が正しく動作するために、実際には事前指定された注釈を使用する必要があります。これは、注釈が追加される前のオブジェクト (実際にはクラス) が POJO であり、注釈が削除されると POJO 状態に戻る場合、そのオブジェクトは依然として POJO と見なすことができるという考え方です。この場合、基本オブジェクトは、実装されたインターフェイスなどの特別な特性を持たないため、「Specialized Java Object」(SJO または (sic) SoJO) として POJO のままです。

JavaBeanは、シリアライズ可能で、引数なしのコンストラクタを持ち、単純な命名規則に従うgetter メソッドと setter メソッドを使用してプロパティにアクセスできる POJO です。この規則により、任意の JavaBeans のプロパティに対して単純な宣言的参照を行うことができます。このような宣言的参照を使用するコードは、Bean のタイプについて何も知る必要はなく、Bean は多くのフレームワークで使用できますが、フレームワークは Bean の正確なタイプを知る必要はありません。JavaBeans 仕様は、完全に実装されている場合、クラスが真の JavaBean であるためにはSerializableインターフェースを実装する必要があるため、POJO モデルをわずかに破ります。いまだに JavaBeans と呼ばれている多くの POJO クラスは、この要件を満たしていません。Serializableはマーカー (メソッドなし) インターフェースであるため、これは大きな負担にはなりません。

以下は、 POJO のプロパティへの 双方向バインディングを持つJavaServer Faces (JSF) コンポーネントの例を示しています。

<h:inputText値 = "#{MyBean.someProperty}" /> 

POJO の定義は次のようになります。

パブリッククラスMyBean {   

    プライベート文字列someProperty ;  

    パブリック文字列getSomeProperty () { somePropertyを返します; }   
          
    

    パブリックvoid setSomeProperty ( String someProperty ) { this . someProperty = someProperty ; } }    
          
    

JavaBean の命名規則により、単一の「someProperty」参照は、値を取得するための「getSomeProperty()」(または、プロパティがブール型の場合は「isSomeProperty()」 ) メソッドに、値を設定するための「setSomeProperty(String)」メソッドに自動的に変換されます。

lombok ライブラリを使用すると、面倒な記述をすることなく、動的にコードを変更してこれらの規則を統合できます。次のコードは、空のコンストラクターを追加して、同じ Bean を生成します。

@NoArgsConstructor
パブリッククラスMyBean {   

    @Getter @SetterプライベートString someProperty ; 
      

}

他のライブラリやフレームワークは、これらの規則に従ってコード (またはバイトコード) を直接生成します。これらのツールを追加すると、定型文が軽減され、バグの頻度とメンテナンス コストが削減されます。

POJO を使用した設計が一般的に使用されるようになると、フレームワークで使用される完全な機能を POJO に提供し、実際に必要な機能領域についてより多くの選択肢を提供するシステムが登場しました。このモデルでは、プログラマーは POJO のみを作成します。この POJO は純粋にビジネス ロジックに焦点を当てており、(エンタープライズ) フレームワークに依存しません。アスペクト指向プログラミング(AOP) フレームワークは、永続性、トランザクション、セキュリティなどの横断的な懸念事項を透過的に追加します。^[6]

Spring はこのアイデアを早期に実装したものであり、このモデルを普及させる原動力の 1 つでした。

EJB Bean が POJO である例:

• エンタープライズJavaBeans (EJB)
• Java Persistence API (JPA) ( Hibernate を含む)
• CDI (Java EE プラットフォームのコンテキストと依存性の注入)

以下は、EJB3 が POJO モデルをどのように活用するかを示す、完全に機能する EJB Bean を示しています。

パブリッククラスHelloWorldService {   

    パブリック文字列sayHello () { return "Hello, world!" ; } }   
         
    

前述のとおり、Bean は EJB クラスを拡張したり、EJB インターフェースを実装したりする必要はなく、EJB アノテーションを含める必要もありません。代わりに、プログラマーは、Bean に追加する EJB サービスを外部XMLファイルで宣言します。

<enterprise-beans> 
<session> <ejb-name> helloWorld </ejb-name> <ejb-class> com.example.HelloWorldService </ejb-class> <session-type>ステートレス</session-type> </session> </enterprise-beans>    
        
        
        
    

実際には、注釈がエレガントであると考える人もいれば、XMLは冗長で見苦しく、保守が難しいと考える人もいます。また、注釈がPOJOモデルを汚染していると考える人もいます。^[7]

そのため、XML の代替として、多くのフレームワーク (Spring、EJB、JPA など) では、XML の代わりに、または XML に加えてアノテーションを使用できます。以下は、上記と同じ EJB Bean ですが、アノテーションが追加されています。この場合、XML ファイルは不要になります。

@Stateless
パブリッククラスHelloWorldService {   

    パブリック文字列sayHello () { return "Hello, world!" ; } }   
         
    

上記の注釈により、Bean はもはや真の純粋な POJO ではなくなりますが、注釈は単なる受動的なメタデータであるため、クラスを拡張したりインターフェースを実装したりする必要があるという侵襲性に比べると、有害な欠点ははるかに少なくなります。^[6]したがって、プログラミング モデルは依然として純粋な POJO モデルに非常に似ています。

POJI（Plain Old Java Interface）はJavaインターフェイスの基本形式であり、より複雑なJavaインターフェイスが許可されていない箇所でも使用できます。^{[8] : 57、572、576、579、1340}

• データ転送オブジェクト(DTO)
• 貧血ドメインモデル
• KISS原則