Einfaches altes Java-Objekt - Plain old Java object

In der Softwaretechnik ist ein einfaches altes Java-Objekt ( POJO ) ein gewöhnliches Java- Objekt , das keiner besonderen Einschränkung unterliegt . Der Begriff wurde im September 2000 von Martin Fowler , Rebecca Parsons und Josh MacKenzie geprägt:

"Wir haben uns gefragt, warum die Leute so gegen die Verwendung regulärer Objekte in ihren Systemen waren und kamen zu dem Schluss, dass es daran lag, dass einfache Objekte keinen ausgefallenen Namen hatten. Also gaben wir ihnen einen, und er hat sich sehr gut durchgesetzt."

Der Begriff "POJO" bezeichnete ursprünglich ein Java-Objekt, das keinem der wichtigsten Java-Objektmodelle, Konventionen oder Frameworks folgt; Heutzutage kann "POJO" auch als Akronym für einfaches altes JavaScript-Objekt verwendet werden, wobei der Begriff in diesem Fall ein JavaScript- Objekt ähnlicher Abstammung bezeichnet.

Der Begriff setzt ein Akronymmuster fort , um Retronyme für Technologien zu prägen , die keine ausgefallenen neuen Funktionen verwenden: Plain Old Ruby Object (PORO) in Ruby , Plain Old Telephone Service (POTS) in Telefonie und Plain Old Documentation (Pod) in Perl . Das Äquivalent zu POJO im .NET Framework ist ein einfaches Old CLR-Objekt (POCO). Für PHP ist es ein einfaches altes PHP-Objekt (POPO).

Das POJO-Phänomen hat höchstwahrscheinlich aufgrund der Notwendigkeit eines gemeinsamen und leicht verständlichen Begriffs, der im Gegensatz zu komplizierten Objekt-Frameworks steht, eine breite Akzeptanz gefunden.

Definition

Idealerweise ist ein POJO ein Java-Objekt, das an keine anderen Einschränkungen gebunden ist als die, die von der Java Language Specification erzwungen werden; dh ein POJO sollte nicht müssen

  1. Erweitern Sie vordefinierte Klassen, wie in
    public class Foo extends javax.servlet.http.HttpServlet { ...
  2. Implementieren Sie vordefinierte Schnittstellen, wie in
    public class Bar implements javax.ejb.EntityBean { ...
  3. Vorgegebene Anmerkungen enthalten , wie in
    @javax.persistence.Entity public class Baz { ...

Aufgrund technischer Schwierigkeiten und anderer Gründe erfordern viele als POJO-konform beschriebene Softwareprodukte oder Frameworks jedoch tatsächlich immer noch die Verwendung vordefinierter Annotationen für Funktionen wie Persistenz, um ordnungsgemäß zu funktionieren. Die Idee ist, dass, wenn das Objekt (eigentlich Klasse) ein POJO war, bevor Anmerkungen hinzugefügt wurden, und zum POJO-Status zurückkehren würde, wenn die Anmerkungen entfernt werden, es immer noch als POJO betrachtet werden kann. Dann bleibt das Basisobjekt insofern ein POJO, als es keine besonderen Eigenschaften (wie zB eine implementierte Schnittstelle) aufweist, die es zu einem "Specialized Java Object" (SJO oder (sic) SoJO) machen.

Kontextabhängige Variationen

JavaBeans

Eine JavaBean ist ein serialisierbares POJO mit einem Konstruktor ohne Argumente und ermöglicht den Zugriff auf Eigenschaften mithilfe von Getter- und Setter-Methoden , die einer einfachen Namenskonvention folgen. Aufgrund dieser Konvention können einfache deklarative Verweise auf die Eigenschaften beliebiger JavaBeans gemacht werden. Code, der eine solche deklarative Referenz verwendet, muss nichts über den Typ der Bean wissen, und die Bean kann mit vielen Frameworks verwendet werden, ohne dass diese Frameworks den genauen Typ der Bean kennen müssen. Die JavaBeans-Spezifikation bricht bei vollständiger Implementierung leicht das POJO-Modell, da die Klasse die Serializable- Schnittstelle implementieren muss , um eine echte JavaBean zu sein. Viele POJO-Klassen, die noch immer JavaBeans genannt werden, erfüllen diese Anforderung nicht. Da Serializable eine (methodenlose) Schnittstelle ist, ist dies keine große Belastung.

Das Folgende zeigt ein Beispiel für eine JavaServer Faces (JSF)-Komponente mit einer bidirektionalen Bindung an eine POJO-Eigenschaft: 

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

Die Definition des POJO kann wie folgt lauten: 

public class MyBean {

    private String someProperty;

    public String getSomeProperty() {
         return someProperty;
    }

    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
}

Aufgrund der JavaBean-Namenskonventionen kann die einzelne "someProperty"-Referenz automatisch in die Methode "getSomeProperty()" (oder "isSomeProperty()", wenn die Eigenschaft vom Booleschen Typ ist ) zum Abrufen eines Werts und in die Methode "setSomeProperty( String)" Methode zum Setzen eines Werts.

Dienste transparent hinzufügen

Da Designs, die POJOs verwenden, immer häufiger verwendet werden, sind Systeme entstanden, die POJOs die volle Funktionalität geben, die in Frameworks verwendet wird, und mehr Auswahl darüber, welche Funktionalitätsbereiche tatsächlich benötigt werden. In diesem Modell erstellt der Programmierer nichts anderes als ein POJO. Dieses POJO konzentriert sich rein auf die Geschäftslogik und hat keine Abhängigkeiten von (Unternehmens-)Frameworks. Aspektorientierte Programmierung (AOP) Frameworks fügen dann transparent übergreifende Anliegen wie Persistenz, Transaktionen, Sicherheit usw. hinzu.

Der Frühling war eine frühe Umsetzung dieser Idee und eine der treibenden Kräfte hinter der Popularisierung dieses Modells.

Ein Beispiel für eine EJB-Bean als POJO:

Das Folgende zeigt eine voll funktionsfähige EJB-Bean, die zeigt, wie EJB3 das POJO-Modell nutzt: 

public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

Wie angegeben, muss das Bean keine EJB-Klasse erweitern, kein EJB-Interface implementieren und auch keine EJB-Annotationen enthalten. Stattdessen deklariert der Programmierer in einer externen XML- Datei, welche EJB-Services der Bean hinzugefügt werden sollen: 

<enterprise-beans>
    <session>
        <ejb-name>helloWorld</ejb-name>
        <ejb-class>com.example.HelloWorldService</ejb-class>
        <session-type>stateless</session-type>
    </session>
</enterprise-beans>

In der Praxis finden manche Leute Annotationen elegant, während sie XML als ausführlich, hässlich und schwer zu pflegen ansehen, andere wiederum finden, dass Annotationen das POJO-Modell verschmutzen.

Daher erlauben viele Frameworks (zB Spring, EJB und JPA) als Alternative zu XML die Verwendung von Annotationen anstelle oder zusätzlich zu XML. Die folgende Abbildung zeigt dieselbe EJB-Bean wie oben, jedoch mit einer hinzugefügten Annotation. In diesem Fall wird die XML-Datei nicht mehr benötigt: 

@Stateless
public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

Mit der oben angegebenen Annotation ist die Bean kein wirklich reines POJO mehr, aber da Annotationen lediglich passive Metadaten sind, hat dies weitaus weniger schädliche Nachteile im Vergleich zu der Invasivität, Klassen zu erweitern und/oder Schnittstellen zu implementieren. Dementsprechend ist das Programmiermodell dem reinen POJO-Modell immer noch sehr ähnlich.

Verwandte Akronyme

Einfaches altes Java-Interface

Ein Plain old Java Interface (POJI) ist eine Grundform der Java-Schnittstelle und an Stellen akzeptabel, an denen komplexere Java-Schnittstellen nicht erlaubt sind.

Siehe auch

Verweise