Plain Old Java Object

POJO ist eine Abkürzung für Plain Old Java Object, also ein „ganz normales“ Objekt in der Programmiersprache Java.

Motivation

Der Ausdruck wurde im September 2000 von Martin Fowler, Rebecca Parsons und Josh MacKenzie mit der Idee geprägt,um einfache Java-Objekte von solchen Objekttypen zu unterscheiden, welche mit vielfältigen externen Abhängigkeiten belastet sind. Solche externen Abhängigkeiten können beispielsweise zwingend zu implementierende Schnittstellen, einzuhaltende Namenskonventionen oder notwendige Annotationen sein. Die grundlegende Idee lautet dabei „je einfacher, desto besser“, auch als KISS-Prinzip bekannt.

“We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.”

„Wir wunderten uns, warum die Leute so gegen die Nutzung regulärer Objekte in ihren Systemen waren und kamen zu dem Schluss, dass einfachen Objekten ein origineller Namen fehlte. Also gaben wir ihnen einen und er hat sich sehr schön durchgesetzt.“

– Martin Fowler, Rebecca Parsons und Josh MacKenzie

Verwendung

Der Begriff wird vor allem im Zusammenhang mit Object-Relational-Mapping-Konzepten und -Tools wie Hibernate oder JDO verwendet, bei denen das Domain Model aus POJOs aufgebaut werden kann, während im Gegensatz dazu bei Entity Beans umfangreiche Konventionen einzuhalten sind.

Eine weitere Domäne, in der der Begriff POJO eingesetzt wird, ist die Welt der Inversion-of-Control-Container wie Spring oder PicoContainer. Auch hier sollen „einfache“ Java-Objekte zum Einsatz kommen, während externe Abhängigkeiten außerhalb dieser vom Container aufgelöst werden.

Variationen

Seit November 2005 wird der Begriff „POJO“ hauptsächlich verwendet, um ein Objekt zu beschreiben, das nicht den großen Java-Objekt-Modellen, Konventionen, oder Frameworks wie EJB entspricht.

Ein POJO ist ein Java-Objekt, das keinerlei Einschränkungen bis auf die der Java Language Specification hat. Das heißt, ein POJO sollte keine:

1. vorspezifizierte Klasse erweitern, wie z. B. hier:

   public class Foo extends javax.servlet.http.HttpServlet { …
   

2. vorspezifiziertes Interface implementieren, wie z. B. hier:

   public class Bar implements javax.ejb.EntityBean { …
   

3. vorspezifizierte Annotation enthalten, wie z. B. hier:

   @javax.ejb.Entity public class Haus { …