29 June, 2004

Software Design Patterns

Te vinden onder: Uncategorized — @ 16:09

Ik ben verdomme al dagen bezig met ook maar iets te begrijpen over hoe ‘the Gang of Four’ hun softwarepatronen ‘het vele werk licht en aangenaam’ maken. Amen! Patronen zijn goed, patronen zijn snel, patronen zijn betrouwbaar en hebben hun degelijkheid al bewezen, maar iets abstracters ben ik nog nooit tegengekomen of het moest mijn voorliefde zijn voor spinaziestoemp.
Welaan, ik heb ondertussen rooddoorlopen ogen, opgedroogde schuim rond mijn bakkes en een verschrikkelijk slecht humeur. De enige patronen die mij nu nog iets zeggen zijn diegene waar ik mijn riotgun mee gevuld heb en waarvan ik zonet de eerste heb doorgeladen. Klak-klak.
Mind me.


reacties (5)


5 reacties, »

  1.   Reactie van Izzydorio , op 30 June, 2004 @ 10:20

    Stel:
    Ge hebt ne webserver met clients (=gebruikers) eraan.
    Uw gebruikers hebben ip-telefoons en die ip-telefoons hangen aan nen (hardware) telefoon-switch.
    Ze kunnen inloggen en uitloggen op die switch via uw webapplicatie.
    Uw webapplicatie doet dat dmv een java-klasse die de switch gaat besturen/uitlezen.
    Er is maar één telefoonswitch (hardwarematig) dus als ge via uw Java-klasske iemand uitlogt van dienen telefoon-switch wilde toch dat alle andere gebruikers die ook als “uitgelogd” ziet?
    Dus dan gebruikt ge een singleton-patroon, zodat iedereen dezelfde instance van die Java klasse gebruikt ipv iedereen een aparte instantie (dan zou die gebruikers enkel als “uitgelogd” staan in zijn Java-instance; voor al die ander is em no ingelogd want ze hebben allemaal een aparte java-klasse!

    Duidelijk :p ?

  2.   Reactie van karma , op 30 June, 2004 @ 19:34

    Ik hoop dat je een engelse versie van het boek hebt. De nederlandse vertaling vond ik nogal belabberd.

  3.   Trackback van Clopin.be , op 9 July, 2004 @ 9:05

    Gmail niet origineel meer
    Hoe origineel het ook was, Gmail is niet alleen! Ik heb een beetje zitten zoeken en al gauw kom je er wat tegen die krak hetzelfde aanbieden. Zelfs sommige zonder reclame (tot hiertoe), om maar te

  4.   Reactie van bvdb , op 7 July, 2007 @ 4:47

    Hoh, design patterns. Het is een abstract idee natuurlijk. En je moet rekening houden met het feit dat dat boek van the gang of 4, inmiddels 12 (?) jaar oud is.

    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.

  5.   Reactie van Polski , op 7 July, 2007 @ 4:51

    merci bvdb voor uw zeergemeende opheldering.

RSS feed voor deze reacties. TrackBack URL

Voeg een reactie toe:

Powered by WordPress