Zum Inhalt springen

Schlagwort: design pattern

ValueObjects (Teil 2)

letzte Woche haben wir ValueObjects kennen gelernt und auch die Möglickeit eines Object-Pools gesehen. Jetzt geht es um einen weiteren Punkt, die Erzeugung valider Objekte. Schließlich kann das Person-Objekt aus der letzten Woche durchaus als Vor- und Nachname null haben. Um daraus entstehende Probleme zu vermeiden, passen wir das ValueObject heute noch etwas an.

ValueObjects (Teil 1)

Eine Diskussion mit einem Kollegen hat mein Interesse für das heutige Thema geweckt. Er wollte unbedingt ValueObjects nutzen, da diese sich in dem entsprechenden Zusammenhang für ihn als einzig sinnvolle Möglichkeit darstellten. Die Implementierung war natürlich schnell erledigt, aber die Frage nach dem warum hat mich doch etwas beschäftigt. Und vor allem, ob man das Konzept in PHP implementieren kann und eins vorweg: klar geht das!

Asynchrones Dilemma

Asynchrone Requests machen das A in AJAX aus und bieten viel Raum für interessante Betrachtungen. Hier geht es heute um das Problem, das veraltete Anfragen sauber erkannt oder alternativ ein hohe Anzahl von Antworten schnell verteilt werden sollen. Anhand einer Abstraktion werde ich den ersten Punkt beispielhaft beschreiben.

Das Factory-Pattern

Heute gibt es wieder einen Beitrag aus der Pattern-Kiste. Das Factory-Pattern ist ein netter Helfer, wenn man eine Klasse erzeugen möchte, den Konstruktor aber nicht so direkt nutzen kann oder will. Man erstellt also eine zweite Klasse, die Factory. In dieser Klasse stellt man Methoden bereit, die ein Objekt der ersten Klasse, die man ja eigentlich nutzen will, zurückliefert. Die Methoden können auch statisch sein. Dagegen spricht mE nichts. Jetzt stellt sich die Frage, wann man ein solches Vorgehen nutzen soll.

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.

Design Pattern: „Singleton“

Da dies der erste Beitrag zum großen Thema „Design Pattern“ ist, gibt es eine kurze Einführung. Ein „Design Pattern“ ist ein Muster in der Softwareentwicklung, das sich bewährt hat und von vielen Leute genauso genutzt wird. Damit man für ein solches Muster auch einen Namen hat, überlegt man sich eine gute Umschreibung und schon hat man ein neues Design Pattern (oder Entwurfsmuster) geschaffen.

Nun gibt es das Singleton. Dies ist eine Klasse, von der es nur eine Instanz gibt. Eigentlich ein recht einfaches Konzept.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close