Que signifie exactement le terme Plain Old Java Object (POJO) ?

Question

Que signifie le terme Plain Old Java Object (POJO) ? Je n'ai rien trouvé d'assez explicatif.

Page Wikipedia de POJO dit que POJO est un objet Java ordinaire et non un objet spécial. Maintenant, qu'est-ce qui rend ou ne rend pas un objet spécial en Java ?

La page ci-dessus indique également qu'une POJO ne doit pas étendre des classes prédéfinies, implémenter des interfaces prédéfinies ou contenir des annotations prédéfinies. Cela signifie-t-il également que les POJO ne sont pas autorisés à implémenter des interfaces comme Serializable, Comparable ou des classes comme Applets ou toute autre classe/interface écrite par l'utilisateur ?

En outre, la politique ci-dessus (pas d'extension, pas de mise en œuvre) signifie-t-elle que nous ne sommes pas autorisés à utiliser des bibliothèques externes ?

Où sont utilisés exactement les POJO ?

EDIT : Pour être plus précis, suis-je autorisé à étendre/implémenter des classes/interfaces qui font partie de la bibliothèque Java ou de toute autre bibliothèque externe ?

Answer 1

Un bon vieil objet Java Ce nom est utilisé pour souligner qu'un objet donné est un objet Java ordinaire, et non un objet spécial tel que ceux définis par le cadre EJB 2.

classe A {}
classe B étend/implémente C {}

Note : B est non POJO quand C est une classe de framework distribué ou ifc. par exemple javax.servlet.http.HttpServlet, javax.ejb.EntityBean ou J2EE extn et non sérialisable/comparable. Puisque serializable/comparable sont valides pour POJO.

Ici, A est un objet simple qui est indépendant. B est un objet spécial puisque B étend/implémente C. Ainsi, l'objet B obtient une signification supplémentaire de C et B est restrictif pour suivre les règles de C. et B est étroitement liés avec un cadre distribué. Par conséquent, l'objet B n'est pas un POJO selon sa définition.

Le code utilisant la classe Une référence d'objet ne doit rien savoir du type de celle-ci, et elle peut être utilisée avec de nombreux frameworks.

Ainsi, une POJO ne devrait pas avoir à 1) étendre des classes pré-spécifiées et 2) implémenter des interfaces pré-spécifiées.

JavaBean est un exemple de POJO qui est sérialisable, possède un constructeur sans argument et permet d'accéder aux propriétés à l'aide de méthodes getter et setter qui suivent une convention d'appellation simple.

POJO se concentre uniquement sur la logique métier et ne dépend pas des cadres (d'entreprise). Cela signifie qu'il possède le code pour la logique métier mais que la façon dont cette instance est créée, le service (EJB ) auquel cet objet appartient et ses caractéristiques spéciales (avec ou sans état) seront décidés par les frameworks en utilisant un fichier xml externe.

Exemple 1 : JAXB est le service qui permet de représenter des objets java en XML. Ces objets java sont simples et sont dotés de getters et setters par défaut.

Exemple 2 : Hibernate où une simple classe java sera utilisée pour représenter une Table. Les colonnes seront ses instances.

Exemple 3 : Services REST. Dans les services REST, nous aurons une couche de service et une couche Dao pour effectuer certaines opérations sur la base de données. Ainsi, Dao aura des requêtes et des opérations spécifiques au fournisseur. La couche de service sera responsable de l'appel de la couche DAO pour effectuer des opérations sur la base de données. Les API (méthodes) de création ou de mise à jour des DAO prendront des POJO comme arguments, et mettront à jour ces POJO et les inséreront dans la base de données. Ces POJO (classe Java) n'auront que des états (variables d'instance) de chaque colonne et ses getters et setters.

Dans la pratique, certaines personnes trouvent les annotations élégantes, alors qu'elles considèrent le XML comme verbeux, laid et difficile à maintenir, d'autres encore trouvent que les annotations polluent le modèle POJO. Ainsi, comme alternative à XML, de nombreux frameworks (par exemple Spring, EJB et JPA) permettent d'utiliser les annotations à la place ou en plus de XML :

Avantages :
Le découplage du code d'application des cadres d'infrastructure est l'un des nombreux avantages de l'utilisation des POJO. L'utilisation des POJO assure la pérennité de la logique métier de votre application en la découplant des cadres d'infrastructure volatiles et en constante évolution. La mise à niveau vers une nouvelle version ou le passage à un autre framework devient plus facile et moins risqué. Les POJO facilitent également les tests, ce qui simplifie et accélère le développement. Votre logique d'entreprise sera plus claire et plus simple car elle ne sera pas enchevêtrée avec le code de l'infrastructure.

Références : wiki source2

Answer 2

Selon Martin Fowler Il l'a inventé avec d'autres pour décrire une classe standard, par opposition à un EJB, etc.

Answer 3

L'utilisation du terme implique ce qu'il est censé vous dire. Si, par exemple, un cadre d'injection de dépendances vous dit que vous pouvez injecter un POJO dans n'importe quel autre POJO, il veut dire que vous ne devez rien faire de spécial : il n'est pas nécessaire d'obéir à des contrats avec votre objet, d'implémenter des interfaces ou d'étendre des classes spéciales. Vous pouvez simplement utiliser ce que vous avez déjà.

UPDATE Pour donner un autre exemple : alors qu'Hibernate peut faire correspondre n'importe quel POJO (n'importe quel objet que vous avez créé) à des tables SQL, dans Core Data (Objective C sur l'iPhone) vos objets doivent étendre NSManagedObject pour que le système puisse les persister dans une base de données. En ce sens, Core Data ne peut pas travailler avec n'importe quel POJO (ou plutôt POOCO=PlainOldObjectiveCObject) alors qu'Hibernate le peut. (Il se peut que je n'aie pas raison à 100% concernant Core Data, car je viens juste de commencer à m'y intéresser. Tous les conseils / corrections sont les bienvenus :-) ).

Answer 4

Plain Old Java Object :)

Eh bien, vous donnez l'impression que ce sont toutes des restrictions terribles.

Dans le contexte habituel où les POJO sont utilisés, il s'agit plutôt d'un avantage :

Cela signifie que la bibliothèque/API avec laquelle vous travaillez est parfaitement disposée à travailler avec des objets Java qui n'ont pas été modifiés ou manipulés de quelque manière que ce soit, c'est-à-dire que vous n'avez rien à faire de spécial pour les faire fonctionner.

Par exemple, le processeur XML XStream sérialisera (je pense) volontiers les classes Java qui n'implémentent pas la fonction Serializable interface. C'est un plus ! De nombreux produits qui utilisent des objets de données vous obligeaient à mettre en œuvre l'interface SomeProprietaryDataObject ou même de prolonger une AbstractProprietaryDataObject classe. De nombreuses bibliothèques s'attendent à un comportement de haricot, c'est-à-dire à des getters et setters.

En général, ce qui fonctionne avec les POJO fonctionne également avec les non-POJO. Ainsi, XStream sérialisera bien sûr aussi les classes Serializable.

Answer 5

POJO est un Plain Old Java Object - par rapport à quelque chose qui a besoin des trucs de Enterprise Edition (J2EE) (beans etc...).

POJO n'est pas vraiment une définition stricte, c'est plutôt une façon de décrire les objets Java "normaux" et non-entreprises. La question de savoir si l'utilisation d'une bibliothèque ou d'un framework externe rend un objet POJO ou non est en quelque sorte dans l'œil de l'observateur, dépendant largement de la bibliothèque/du framework, bien que je m'aventurerais à dire qu'un framework rendrait quelque chose moins POJO.