Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03375.jsonl.gz/2117

Entwurfsmuster für Objekte
Business Object
Das Geschäftsobjekt ist das Ding mit dem die meisten von uns Erfahrung haben. Das Model (M) in MVC. Es bildet ein reales Ding aus dem Geschäftsfeld (auch Domäne/Domain genannt) der Applikation ab. In einer Kalenderapplikation wären dies z.B. Termin, Erinnerung, Einladung, usw.
Meist sind BOs Entitäten. Das bedeutet, dass das Objekt eine eindeutige Identität hat (z.B. durch eine
ID). Die Entität wird deshalb nicht durch ihre Attribute und Werte, sondern nur durch ihre Identität ... identifiziert. Siehe als Vergleich Value Objects.
Die BOs interagieren meist miteinander und entwickeln Abhängigkeiten. So kann man einem Termin etwa Erinnerungen oder Einladungen hinzufügen. Und letztere interagieren dann wieder mit Teilnehmern.
Die Kernaufgaben, oder die Geschäftslogik, einer Applikation sind normalerweise in den BOs abgebildet - und nicht etwa in Controllern oder gar einer Library. Im Idealfall ist die Geschäftslogik (Wer kann an einem Termin teilnehmen?, An welchen Tagen habe ich frei?, Wann muss ich eine Erinnerung verschicken?, etc.) komplett losgelöst von Frameworks und Libraries. Meist ist eine Applikation auch in Teilsysteme (oder Module) eingeteilt, die dann eigene BOs haben, die von ihrer Aussenwelt keine Ahnung haben. Z.B. braucht das CMS keine Kenntnisse über die BOs im Buchungsmodul zu haben.
Wenn die Geschäftslogik nicht in den BOs, sondern z.B. in Services ausgelagert wird, nennt man das Anemic Domain Model. Dieses gilt aber eher als Anti-Pattern.
- http://devlicio.us/blogs/casey/archive/2009/02/13/ddd-entities-and-value-objects.aspx
- http://www.martinfowler.com/bliki/AnemicDomainModel.html
Value Object
VO sind simple Objekte, die bei selbem Wert (value) als gleich betrachtet werden. Nehmen wir zum Beispiel Geldscheine. Zwei Geldschein Objekte mit dem Wert
10.- werden als gleich angesehen. Für mich ist total egal, welches der beiden Objekte ich besitze, ich will nur die Knete haben. VOs werden also durch ihre Attribute und Werte identifiziert und besitzen keine eindeutige Identität.
Bin ich aber eine Notenbank, dann muss die Note plötzlich eine Identität, z.B. eine Seriennummer, haben und eindeutig identifizierbar sein. Für die Notenbank sind Geldscheine Entitäten. Es hängt also immer vom Kontext ab, wie Objekte einzuordnen und zu gestalten sind.
In der Regel sind VOs unveränderlich (immutable). Das heisst, dass sich nach der Initialisierung die Werte des Objektes nicht mehr ändern lassen. Die
10.- Note wird nicht plötzlich zu einer
100.- Note. Und die Farbe
Rot wird nicht auf einmal
Blau. Weitere Beispiele sind Adresse, Datum oder Zeitraum.
- http://martinfowler.com/eaaCatalog/valueObject.html
- http://devlicio.us/blogs/casey/archive/2009/02/13/ddd-entities-and-value-objects.aspx
Data Transfer Object
DTOs sind simple Objekte die dazu eingesetzt werden, Daten zwischen Teilsystemen einer Applikationen zu übertragen. Sie sollten keine Funktionalität besitzen und einfach nur ihre eigenen Daten halten und verfügbar machen. Alle Felder sollten primitive Datentypen sein, die sich serialisieren lassen. So lässt sich ein DTO auch als XML oder JSON abbilden und über das Netzwerk übertragen. Oder in eine Datei speichern. Oder in eine Queue stecken. Oder ...
Meist sind DTOs ein Aggregat aus mehrern Geschäftsobjekten. Für Termin, Erinnerung und Teilnehmern Objekte liesse sich z.B. ein Mailauftrag DTO erstellen, welches anschliessend an ein Mailermodul übergeben werden könnte. Das Mailermodule könnte aus diesem Mailauftrag dann wieder Geschäftsobjekte aus seiner eigenen Domäne erstellen und mit dieser weiterarbeiten.
- http://martinfowler.com/eaaCatalog/dataTransferObject.html
POPO
POPO steht für Plain Old PHP Object, angelehnt an POCO (C#) und POJO (Java).
Martin Fowler meinte zur Erstehung des Begriffs:
Wir fragten uns, warum die Leute so dagegen waren, in ihren Systemen reguläre Objekte zu nutzen und kamen zu dem Schluss, dass ein origineller Name für einfache Objekte fehlte. Also gaben wir ihnen einen, und er wurde sehr gut angenommen.
Als PHP Entwickler ist dies jetzt etwas schwierig nachzuvollziehen. Im Java Universium gibt es viele Konventionen wie Objekte modelliert werden sollten (Stichwort EJB), was dazu führte, dass simple Klassen etwas in Vergessenheit gerieten.
POPOs sind also einfach Objekte von Klassen, die keinen allzu grossen Konventionen unterliegen. Sie implementieren nicht fünf Interfaces und haben einen riesigen Rattschwanz an Superklassen.
- http://de.wikipedia.org/wiki/PlainOldJava_Object
- http://rlacovara.blogspot.ch/2009/03/what-is-difference-between-dto-and-poco.html
Ähnliche Artikel
- La Retrospectiva #2: OOP, Irische Pubs, Digitale Güter, Dropbox, Batman
- Der gelegentlich nützliche Ratschlag von Demeter
- Statische Methoden sind einfach nur Funktionen - also Vorsicht!