Het observer pattern bijvoorbeeld, super goed gekend. Makkelijk te begrijpen in mijn ogen. Maar in de modernere OOP talen zoals C# bijvoorbeeld gebeurt het tegenwoordig met events. Dus daar kan de oplossing in het boek natuurlijk niet aan tippen.

Het decorator pattern bijvoorbeeld, schitterende oplossing voor overervingsproblemen. Maar tussen ons gezegd en gezwegen, zodra je reflectie gaat gebruiken: de is-operator , het typeof keyword of de Type property verpesten het hele patroon.

Ik gebruik in het algemeen een 3-8tal design patterns uit het boek wanneer ik aan een groot project werk (zoals mijn eindwerk, of een spel ofzo). Maar ik heb ook een aantal concepten die ik als mijn eigen patronen beschouw. Oplossingen voor duidelijk terugkerende problemen die niet in het boek besproken worden. Het boek is niet altijd perfect. Ik beschouw het veel meer als een inspiratiebron die je af en toe eens doet denken: “aha, die optie had ik over het hoofd gezien”.

Sommige patronen gebruik ik bijzonder vaak zoals: MVC-model, observer, strategy, factory, decorator, singleton, command, …

Maar de meeste kom ik zelden of nooit tegen.

Wat het voorbeeld van Izzydorio betreft: gevaarlijk voorbeeld, Izzy. Het singleton patroon is waarschijnlijk het meest misbruikte patroon dat er is. Voor het gegeven voorbeeld is het helemaal niet zeker of het singleton pattern echt de beste oplossing is. Ik denk persoonlijk van niet. Waarom niet: Je omschrijving doet vermoeden dat elke instantie een telefoonswitch voorstelt. Waarom zou je dan niet gewoon vooraf één instantie maken en diezelfde instantie gewoon vooraf doorgeven? Ook in dat geval zullen alle gebruikers dezelfde instantie gebruiken, zonder dat hiervoor het singleton pattern nodig is. Het lijkt er mij sterk op dat je het singleton pattern niet gaat gebruiken als een creatiepatroon maar als een middel om de scope van je objecten te verkrachten. Dat mag eigenlijk niet. Je kunt je misschien afvragen: “wanneer mag ik het singleton pattern dan WEL gebruiken?”.

Om te beginnen is het belangrijk dat je vooraf uitmaakt: KAN het ooit mogelijk worden dat er verschillende instanties nodig zijn. Is het antwoord neen, dan heb je het singleton pattern niet nodig, maar gewoon een statische klasse. Wordt het in theorie WEL mogelijk dat je meerdere instanties nodig hebt, dan moet je goed onthouden dat je het gebruik van de GetInstance enkel mag gebruiken op plaatsen waar de instantie normaal werd aangemaakt. Je mag dus niet bij elke gebruiker zomaar eventjes de GetInstance gaan gebruiken, want dat verklapt dat je nooit van plan zult zijn om meerdere instanties te gebruiken OF dat je vals speelt met de scope van je objecten en het object gewoon niet wilt doorgeven.

Laatste kleine opmerking misschien: Het is inderdaad een HEEL zwaar en uitputtend boek als je er de eerste keer door gaat. Niet direct iets om savonds in je bed te lezen. De meeste dingen worden vaak eenvoudiger geïntroduceerd op websites. Daar lees ik de patronen eerst, en daarna kijk ik eens in het boek.

Duidelijk :p ?