Artikelformat

Design Pattern: Fluent Interface

Diese Design Pattern ist sehr interessant und dabei auch noch sehr einfach. Wenn man eine Klasse definiert hat man normalerweise private Attribute, die man über Setter und Getter anspricht. Wenn man 3-4 Attribute auf einmal befüllen will, kann man eine convenience-Methode definieren. Dies hat den Nachteil, dass man Sinn eines Wertes nicht auf den ersten Blick sieht und man dann doch die IDE bemühen muss. Alternativ kann man auch die Setter nacheinander aufrufen. Um das ganze zu verschönern und zu vereinfachen nutzt man ein Fluent Interface.

Man passt nur die Setter an, sodass diese Methoden die Instanz zurückgeben. Dadurch kann man die Setter aneinander reihen. Als Beispiel gibt es die Klasse Person.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class Person {
 
    private $nachname;
    private $vorname;
    private $strasse;
    private $plz;
    private $ort;
 
    function setNachname($nachname) {
        $this->nachname = $nachname;
        return $this;
    }
 
    function setVorname($vorname) {
        $this->vorname = $vorname;
        return $this;
    }
 
    function setStrasse($strasse) {
        $this->strasse = $strasse;
        return $this;
    }
 
    function setPlz($plz) {
        $this->plz = $plz;
        return $this;
    }
 
    function setOrt($ort) {
        $this->ort = $ort;
        return $this;
    }
}

Ein Aufruf sieht dann so aus:

1
2
3
$myPerson = new Person();
$myPerson->setVorname("Max")->setNachname("Mustermann");
$myPerson->setOrt("Musterstadt")->setPlz("1234");

Die Methoden kann man natürlich alle hintereinande reihen, hier wäre dies aber zu unübersichtlich.

Ein sehr prominentes Beispiel für dieses Design Pattern ist die js-Bibliothek jQuery. Interessant ist, dass dieses Designpattern nicht nur eine effizientere Entwicklung ermöglicht, sondern auch mit sehr wenig Aufwand zu realisieren ist.

6 Kommentare

    • Ein sehr gutes Buch, wie ich finde. Aber fluent interface ist mW nicht da drin behandelt. Ich bin auf dieses Pattern durch einen Java-Kollegen gekommen, der mir von Mockito, einem Mocking Framework, vorgeschwärmt hat. Das wurde mit diesem Pattern im Hinterkopf implementiert.

    • Ist lange her, dass ich da drin gelesen hatte. Ich denke, man kann einiges aus der Java-Welt mitnehmen und die PHP Konzepte anreichern. Wird sich in den nächsten Beiträgen zeigen, wie ich meine. Wie heißts so schön: stay tuned.

  1. Hallo zusammen, sehr schöner Post.

    Den Nachteil bei einem FluentInterface ist allerdings, dass man durch das Chaining weniger gut debuggen kann. Das Pattern könnte beispielsweise auch auf andere Anwendungsfälle angewendet werden, bei denen die Operation vielleicht etwas komplexer ist und somit wäre ein Chaining wieder unschön, wie ich finde.

    Bei dem reinen setzen von private membern bietet sich natürlich auch der Konstruktor an.

    Andere Meinungen dazu?

    Grüße

    David Lambauer

    Antworten
    • Naja, grundsätzlich sind Design Patterns ja auch eine gewisse Geschmacksfrage. Vor- und Nachteile lassen sich immer finden und somit muss man für sich, sein Team oder das Produkt den besten Weg wählen.

      Klar, debuggen kann schwerer sein, man kann aber auch die Breakpoints in die Methoden setzen. Und es gibt durchaus Anwendungsfälle, bei denen es praktisch ist nur bestimmte Werte zu setzen. Das Builder Pattern ist hier zu nennen und das wird auch ganz gerne mit einem Fluent Interface angewendet, da man sich eben viele Konstruktoren sparen kann. Bpsw hier: https://code.google.com/p/guava-libraries/wiki/CachesExplained

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.