「Plain Old Java Object」の版間の差分

削除された内容 追加された内容
m ボット: 言語間リンク 13 件をウィキデータ上の (d:Q559344 に転記)
セクション整理, 関連項目・外部リンク追加, リンク, 体裁など
1行目:
'''Plain Old Java Object''' ('''POJO''') は、ある[[Java]]オブジェクトが[[Enterprise JavaBeans|EJB]](特に[[EJB 3]]より前のEJB)EJB)のように特殊なものではなく、ごく普通のJavaオブジェクトであることを強調した名称。設計はシンプルであればあるほど良いと主張する人たちが好んで使用する。2000年9月に[[マーティン・ファウラー]]と[[レベッカ・パーソンズ]]、[[ジョシュ・マッケンジー]]がこの用語を使い始めた。「システムに普通のオブジェクトを使うことに強い抵抗を持つ人が多いのはなぜかと考えたとき、それは単純なオブジェクトに良い名前がついていないのが原因だという結論に達した。そこで我々が名前をつけたら、それがとても流行りだした」[http://www.martinfowler.com/bliki/POJO.html] この命名法は、[[テレフォニー]]におけるPOTS([[Plain Old Telephone Service]])や、[[C++]]で書かれているが[[C言語]]の機能しか使わないPODS([[Plain Old Data Structures]])など、高級な新機能を使わない技術に対する既存の用語と同じパターンに従っている。
 
== 概要 ==
この用語が広く受け入れられた背景には、複雑で特殊なオブジェクト[[アプリケーションフレームワーク|フレームワーク]]と対照的な、一般的で理解しやすい用語が求められていたことがあると思われる。この用語は、[[Java Beans|JavaBeans]]と[[Enterprise JavaBeans]]の名前が衝突しているJava "bean"用語よりも魅力的である。JavaBeansは、厳格な命名規約を持つ[[シリアライズ]]可能なPOJOであるとほぼ言える一方、Enterprise JavaBeansは単一クラスではなく、まったくの[[ソフトウェア部品|コンポーネント]]モデルである(ここでもEJB 3は差が減ってきている)。
[[2000年]]9月に[[マーティン・ファウラー]]と[[レベッカ・パーソンズ]]、[[ジョシュ・マッケンジー]]がこの用語を使い始めた。「システムに普通のオブジェクトを使うことに強い抵抗を持つ人が多いのはなぜかと考えたとき、それは単純なオブジェクトに良い名前がついていないのが原因だという結論に達した。そこで我々が名前をつけたら、それがとても流行りだした。」[http://www.martinfowler.com/bliki/POJO.html] この命名法は、[[電気通信役務|テレフォニー]]におけるPOTS ([[Plain Old Telephone Service]]) や、[[C++]]で書かれているが[[C言語]]の機能しか使わないPODS ({{仮リンク|Plain Old Data Structures|en|Plain old data structure}}) など、高級な新機能を使わない技術に対する既存の用語と同じパターンに従っている。
 
この用語が広く受け入れられた背景には、複雑で特殊なオブジェクト[[アプリケーションフレームワーク|フレームワーク]]と対照的な、一般的で理解しやすい用語が求められていたことがあると思われる。この用語は、[[Java Beans|JavaBeans]]と[[Enterprise JavaBeans]]の名前が衝突しているJava "bean"用語よりも魅力的である。JavaBeansは、厳格な命名規約を持つ[[シリアライズ]]可能なPOJOであるとほぼ言える一方、Enterprise JavaBeansは単一クラスではなく、まったくの[[ソフトウェア部品|コンポーネント]]モデルである(ここでも(ただしEJB 3以降は差が減ってきている)
 
POJOの概念は、明らかにPOJOという用語より前から存在する。なぜなら、オブジェクトクラスの自然なありさまとは、何ら特別なものではないからである。この用語の功績は、何らかのフレームワークを使う利点がその複雑さを補ってあまりあるかどうかということを開発者に考えさせるという点にある。シンプルな設計の方が優れている場合もあるということを思い出させる明確な用語がなくては、複雑なフレームワークが十分な理由のないまま[[システムアーキテクチャ]]に含まれてしまいやすい。POJOによる設計が一般的になるにつれて、大規模フレームワークの機能の一部はPOJOでも実現できることが明らかになってきており、実際に必要な機能領域に対する選択肢は増えている。[[Hibernate]]と[[Spring]]がその例である。
 
== 曖昧さの可能性 ==
[[2005年]]11月時点で、"POJO"という用語は主に、いかなる(主要な)Java)Javaオブジェクトモデル、規約、フレームワーク(たとえばEJB)EJB)にも従わないJavaオブジェクトを指して使われている。しかし、モデルやフレームワークが将来的に変化する可能性や、またこのような分類自体が文脈に依存するという事実を考慮すると、その定義は本質的に不安定で曖昧である。
 
2005年11月時点で、"POJO"という用語は主に、いかなる(主要な)Javaオブジェクトモデル、規約、フレームワーク(たとえばEJB)にも従わないJavaオブジェクトを指して使われている。しかし、モデルやフレームワークが将来的に変化する可能性や、またこのような分類自体が文脈に依存するという事実を考慮すると、その定義は本質的に不安定で曖昧である。
 
厳密に言えば、POJOは全てのJavaオブジェクトを指す用語とも言える。この解釈に基づけば、POJOに関連する記述は全てのJavaオブジェクトに例外なく当てはまらなければならない。しかし、多くの人はこの意見に反対している。
 
EJB 3の仕様はPOJOプログラミングモデルであることを宣言しており、EJB3 Session BeanをPOJOとして記述している。ただし、通常は[[アノテーション]]を必要とする。
 
== 関連項目 ==
* [[JavaBeans]]
* [[Enterprise JavaBeans]] (EJB)
 
== 外部リンク ==
* [http://e-words.jp/w/POJO.html IT用語辞典e-Words - POJO]
 
[[Category:Java]]