Ce terme est de plus en plus utilisé comme synonyme de « classe Java », ce qui est une erreur. Alors, qu’est-ce qu’un POJO au juste ? Et bien, ma définition en serait : une classe Java sans contraintes particulières.

En fait, il n’y a pas de POJO sans framework. Un framework peut vous demander de sous-classer telle ou telle classe, respecter telle convention de nommage, limiter ci, imposer cela. A l’opposé (et un peu en réaction aux EJB), on parle de POJO quand le framework justement n’impose rien sur vos classes Java : vous développez old-school, classes et interfaces sont conçues librement.

Exemple de framework pas-POJO-du-tout :

« Sous-classez com.framework.AbstractPrintableObject, avec un constructeur public à un paramètre de type com.framework.PrintEnvironment. Ne définissez que des méthodes publiques non synchronisées qui lèvent comme exceptions des sous-classes de com.framework.PrintException. etc… etc… »

Le même, façon j’aime-les-POJO :

« Passez-lui un POJO, le framework d’impression essaiera de découvrir ses getters publics et de construire une représentation textuelle imprimable. »

Je précise que j’écris ça dans un souci d’illustration, loin de moi l’idée de suggérer une quelconque supériorité d’une approche tout-POJO par rapport au framework de grand-papa qui offre un lot de superclasses abstraites. Par exemple, je trouve l’approche « pur-POJOs (ah oui, plus plein d’annotations) » un peu hypocrite… :whistle: