template pattern vs strategy pattern

Met het strategy pattern kun je "at runtime" verschillende algoritmen inzetten. Met het template method pattern definieer je één algoritme waarvan onderdelen worden gedelegeerd aan subklassen.

>> Ik heb zelf een abstracte autoloader class waarvan de loadClass method abstract is. De child class extend de abstracte class en moet deze loadClass method dan zelf invullen.

Laten we aannemen dat je hier goede redenen hebt om een abstracte klasse te gebruiken in plaats van een interface... Bepaalde delen van het autoloader-algoritme staan dan al in de abstracte klasse en je gebruikt afgeleide klassen om andere delen van het algoritme in te laten vullen. Dat klinkt als een template method pattern.

Als je namespaces en de autoloader-functionaliteit van PHP 5.3+ gebruikt, is er geen reden om "at runtime" met een strategy pattern compleet andere autoloading-algoritmen te laden.

Ah oké, dankjewel Ward. Dan heb ik dat met die autoloader in ieder geval goed gedaan.

Ik vind het lastig om te bepalen wanneer ik wat moet gebruiken. Stel je hebt verschillende typen voertuigen, dan zou ik zelf gelijk denken aan een abstracte Vehicle class, en een child "car" en "bike" class. Echter, Wouter wees me er gisteren op dat het dan beter is om het Strategy pattern te gebruiken.

Wouter zei ook dat het beter is om 1 User class te hebben, waarin je verschillende rollen aan een User toekent, terwijl ik toch ook vaak heb gezien dat er gebruik wordt gemaakt van een "default" user class, die dan ge-extend wordt door child classes.

Zelf zou ik bijv. eerder denken aan een "class Admin extends User", maar Wouter zegt dat dit niet klopt, omdat we allemaal Users zijn, en dat er dus geen verschillende typen users zijn. Hij zou dus zoiets doen: $admin = new User(); $admin->setRole('admin'). Hoe kijk jij daar tegenaan?

Er is hier geen beste oplossing. Bij softwarearchitectuur moet je in de eerste plaats uitgaan van wat je wilt kunnen bouwen. Daarom is er nogal een verschil tussen een generalistisch framework waarmee je alles kunt bouwen of een meer specialistsch platform dat is bedoeld voor afgebakende toepassingen.

Bij webapplicaties is de front-end vaak een geheel andere applicatie dan de back-end. Een admin bestaat niet in een front-end, alleen in de back-end. Het zijn twee compleet verschillende typen users voor twee gescheiden applicaties. Ik zou dus niet eens zeggen dat een admin een user met een speciale rol is; het is geheel andere user.

Je moet ergens beginnen. En je kunt het niet té abstract modelleren, anders krijg je zo'n taxonomie:

class Animal
  class Chordate extends Animal
    class Tetrapode extends Chordate
      class Mammaliaform extends Tetrapode 
        class Mammal extends Mammaliaform 
          class Human extends Mammal
            class User extends Human

Haha, interessant Ward. Dat zijn dus ook dingen waar ik over loop na te denken.

>> Ik zou dus niet eens zeggen dat een admin een user met een speciale rol is; het is geheel andere user.

Maar valt een admin in jouw optiek dan wel onder de categorie users? Ik zie zelf een user als een gebruiker van het systeem. Een admin zie ik dan als een ander type user, namelijk een user die toegang heeft tot de back-end en daar bepaalde dingen mag doen. Maar ik zie het wel als een user. Dus ik zou dan dit doen:

class Admin extends User

Is dat hetzelfde als wat jij bedoelt?

>> Je moet ergens beginnen. En je kunt het niet té abstract modelleren, anders krijg je zo'n taxonomie:

Hehe :)

Ik denk zeker wel dat je bijv. in deze site niet met aparte klassen kunt werken voor verschillende rechten. De een heeft namelijk rechten van een normaal lid, de ander mag nieuwsberichten modereren, weer een ander tutorials en scripts, sommige het forum, andere mogen het forum én de tutorials modereren, andere weer alleen de boekensectie. Als laatst heb je nog beheerders die dit allemaal mogen + nog andere beheer functies en dan heb je nog super beheerders die praktisch alles kunnen.
Wil je voor elke mogelijke combinatie een nieuwe user-child klasse maken?

Eens, Wouter, maar daarom ook zou ik een forum anders bouwen dan bijvoorbeeld een webwinkel. Wil je daarentegen een framework bouwen dat beide én meer kan, dan los je dat anders op.

Mijn punt, ook in eerdere topics van afgelopen week, is dat je niet steeds moet proberen met één model alles te doen.

Nee, dat lijkt me te ver gaan, maar ik kan me wel een hiërarchie als deze voorstellen:

- user        (geregistreerd bezoeker/lid van de website, zoals ikzelf)
- admin       (iemand die (bepaalde) zaken mag beheren en toegang heeft tot de back-end, zoals jij)
- super-admin (iemand die alles mag, zoals Bas)

Voor de admins kun je dan voor bepaalde onderdelen rechten toekennen.

Wat vind je van deze gedachte?

Dan zou ik dat liever uitsplitsen in gebruikers + groepen + rechten:

- gebruikers: wie?
- rechten: wat?
- groepen: wie mag wat?

In een datamodel is 'groepen' dan een koppeltabel.

Nu ga je 2 dingen combineren, daar ben ik geen fan van. Want hoe ga je nu kijken of iemand iets mag? Eerst instance checken en daarna nog roles? Waarom die niet meteen overal met roles of instances werken?

>> Dan zou ik dat liever uitsplitsen in gebruikers + groepen + rechten:

Kun je een klein voorbeeldje geven van welke classes je dan zou krijgen? Kun je een concrete invulling aan jouw voorbeeld geven zodat ik beter begrijp wat je bedoelt?

>> Eerst instance checken en daarna nog roles?

Dat is wel waar het op neer komt. Stel, jij mag bijv. een bericht van iemand anders editen. Maar een "normale" gebruiker mag dat niet. Op het moment dat een normale gebruiker is ingelogd, wil ik dus niet eens checken of hij een beheer-functie mag uitvoeren, want dat mag hij sowieso niet omdat hij een gebruiker is en geen admin.

Even een stomme analogie... maar bij iemand die geen rijbewijs heeft, ga je ook niet controleren of hij met een aanhanger mag rijden. Hij heeft geen rijbewijs, dus hij mag sowieso niet rijden.