Hoeveel principes heeft het ontwerppatroon eigenlijk?
Categories:
De vroegste samengevatte ontwerppatronen waren er slechts 5, namelijk SOLID:
Enkele verantwoordelijkheidsprincipe (Single Responsibility Principle, SRP): Een klasse zou slechts één reden moeten hebben om te veranderen, dat wil zeggen dat een klasse slechts één verantwoordelijkheid zou moeten hebben.Open-gesloten principe (Open/Closed Principle, OCP): Software-entiteiten (klassen, modules, functies, enz.) zouden open moeten zijn voor uitbreiding en gesloten voor modificatie, dat wil zeggen dat veranderingen zouden moeten worden gerealiseerd door uitbreiding in plaats van door het wijzigen van bestaande code.Liskov-substitutieprincipe (Liskov Substitution Principle, LSP): Subtypen moeten hun basistypen kunnen vervangen, dat wil zeggen dat afgeleide klassen hun basisklassen moeten kunnen vervangen zonder de correctheid van het programma te beïnvloeden.Interface-afschermingsprincipe (Interface Segregation Principle, ISP): Clients zouden niet gedwongen moeten worden afhankelijk te zijn van interfaces die ze niet gebruiken. Grote interfaces zouden moeten worden opgesplitst in kleinere, specifieker gerichte interfaces, zodat clients alleen de methoden hoeven te kennen die ze nodig hebben.Afhangingsinversieprincipe (Dependency Inversion Principle, DIP): Hogere modules zouden niet afhankelijk moeten zijn van lagere modules; beide zouden afhankelijk moeten zijn van abstracties. Abstracties zouden niet afhankelijk moeten zijn van concrete implementatie details, en concrete implementatie details zouden afhankelijk moeten zijn van abstracties.
Later werden twee regels toegevoegd. Deze later toegevoegde regels zijn concreter en richtinggevender dan de vorige. We kunnen zien uit de principesverklaringen dat SOLID beschrijft wat er gedaan moet worden, terwijl de later toegevoegde regels beschrijven wat het beste of voordeligst is om te doen.
Samenstelling/Aggregatie hergebruiksprincipe (Composition/Aggregation Reuse Principle, CARP): Er zou voorrang moeten worden gegeven aan objectcompositie (samenstelling) en aggregatie in plaats van overerving om codehergebruik te bereiken.Wet van Demeter (Law of Demeter, LoD): Een object zou zo min mogelijk van andere objecten moeten weten, dat wil zeggen dat een object zo min mogelijk van de interne structuur en implementatiedetails van andere objecten zou moeten weten.
Naast de bovenstaande genoemde algemene ontwerp principes zijn er ook nog andere ontwerp principes, die misschien niet zo algemeen bekend zijn als de eerdergenoemde, maar toch een belangrijke leidende rol spelen bij software ontwerp en architectuur. Deze later voorgestelde regels zijn een beetje overbodig, en ik denk in ieder geval dat ze niet tegen de intuïtie ingaan en niet diep nadenken vereisen.
Principe van minste kennis (Principle of Least Knowledge, PoLK): Ook bekend als een uitbreiding van de Wet van Demeter, stelt dit principe dat een object zo min mogelijk van andere objecten zou moeten weten. De oorsprong van dit principe kan worden teruggevoerd tot de ‘Wet van Minste Communicatie’ die in 1987 werd voorgesteld door Patricia Lago en Koos Visser.Stabiele afhankelijkheidsprincipe (Stable Dependencies Principle, SDP): Dit principe stelt dat software ontwerp ervoor moet zorgen dat stabiele componenten niet afhankelijk zijn van instabiele componenten, dat wil zeggen dat componenten met een hogere stabiliteit minder afhankelijk zouden moeten zijn van componenten met een lagere stabiliteit. Dit principe is afkomstig uit diepgaand onderzoek naar de relaties tussen componenten in softwaresystemen.Stabiele abstractieprincipe (Stable Abstraction Principle, SAP): In overeenstemming met het stabiele afhankelijkheidsprincipe, leidt dit principe bij het afstemmen van abstractie op stabiliteit, dat wil zeggen dat stabiele componenten abstract zouden moeten zijn en instabiele componenten concreet zouden moeten zijn. Dit principe helpt bij het waarborgen van stabiliteit en flexibiliteit van softwaresystemen.