Alles rund ums Software Development
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.
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!
Obwohl PHP als Template-Sprache entworfen wurde, gibt es inzwischen viele Templatesysteme, die in PHP geschrieben sind. Diese stellen Daten bspw. als HTML-Code dar. Dieser Beitrag befasst sich nun mit dem Two Step View Design Pattern, das in PHP umgesetzt werden kann und dabei fast kein PHP nutzt. Dieser Widerspruch wird nun aufgeklärt.
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.
Nachdem ich im letzten Beitrag ein sehr bekanntes Pattern angesprochen habe und dies auch mit einigen Kommentaren gewürdigt wurde, möchte ich heute ein etwas anderes Pattern vorstellen. Dabei handelt es sich um das Event Collaboration Pattern. GWT-Entwickler werden dieses Pattern kennen, in der PHP Welt kenne ich nur eine ähnliche Implementierung.
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.
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.
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.
