[OOP] Het uitdenken van een CMS
Ik ben al enige tijd bezig met het uitdenken van een CMS. Ik probeer zoveel mogelijk functionaliteiten in te voegen zodat ik gelijk op veel punten terecht kom en zoveel mogelijk leer. Dat is immers het voornaamste doel van dit project.
Nu heeft Wouter J mij in een vorig topic behoorlijk geholpen. Aan de hand hiervan ben ik toch nog verder gaan zoeken naar uitleg over interfaces en abstract classes. Ik vroeg mij nu af gebruik ik het nu niet overkill? Is mijn huidige opzet wel OOP? Zou ik hiermee verder kunnen als ik een simpele cms wil bouwen? Mis ik dingen?
Mij nieuwe opzet is hier te vinden: klikerdeklik
Altijd in voor opbouwende kritiek.
Gr, Milo
Gewijzigd op 17/01/2013 19:37:48 door Milo S
Niet waar? Persoonlijk lijken abstract klasse mij dan handiger in deze situatie omdat je dan niet dubbel werk zit te doen. Je kunt direct methodes waardes meegeven.
Als ik fout zit hoor ik dit graag.
Nicky Monsma op 17/01/2013 20:10:07:
ik zou geen interfaces gebruiken het is negens voor nodig interfaces is bedoelt voor andere developers die kunnen dan kijken welke functions er in de class zit
....
Interfaces, mits juist gebruikt, zijn zo ongeveer het belangrijkste van een OOP omgeving. Het stelt je namelijk in staat om de structuur van de classes vast te zetten, zonder er nog een implementatie aan te hangen. Als je zorgt dat alle (belangrijke, structuur) classes zijn gebouwd naar een interface, dan kan je later op een veilige manier een class vervangen door een andere class. Als alle public methods namelijk zijn gedefinieerd door een interface dan kunnen classes die gebruik van die nieuwe class dat zonder problemen doen.
Neem als voorbeeld een class die je data ophaalt vanuit het model. In eerste instantie doe je dit wellicht vanuit een simpel bestand, omdat de site klein in. Later wil je dat in een database stoppen. Geen probleem, zolang de controller het model aanroept via door de interface gedefinieerde methods, kan je eenvoudig het ene model door het andere vervangen. De controller weet het niet eens, die roept gewoon de bekende method aan.
Ook kan je door middel van type hinting verplicht stellen dat een class een bepaalde interface implementeert. Zo weet de ontvangende class zeker dat het doorgegeven object ook daadwerkelijk de bepaalde methodes implementeert.
Milo S op 17/01/2013 20:23:46:
Persoonlijk lijken abstract klasse mij dan handiger in deze situatie omdat je dan niet dubbel werk zit te doen. Je kunt direct methodes waardes meegeven.
Kijk uit met het gebruik van abstracte classes en overerving. Dat is zo ongeveer het meest misbruikte onderdeel van OOP. Ja, het kan je dubbel werk schelen, maar het is niet altijd de beste manier. Het kan snel ook betekenen dat je bepaalde functionaliteit in een class hebt die je niet nodig hebt.
Als het gaat om het bepalen van welke methodes een class moet hebben, dan kan je dat beter via een interface regelen dan via een (abstracte) basis class.
Toevoeging op 17/01/2013 22:28:05:
Nicky Monsma op 17/01/2013 22:25:26:
Yeah Right you sucks dude
Dank je, ik ben blij dat je het zo sportief opneemt.
Een interface zegt je alleen maar welke methoden een klasse moet hebben. dit kan handig zijn wanneer een klas bepaalde methoden MOET hebben om te kunnen werken.
Het verschil tussen een interface en abstracte klassen is dat abstracte klassen gewoon klassen zijn maar buiten dat feit om kan je in een abstracte klasse dus ook al dingen voor definieren.
vb
Code (php)
zoals je ziet wordt de kleur al voorgedefinieerd. het verschil tussen de abstracte klasse en de interface is dat je in een interface kale methoden hebt een soort van een contract om 100 huizen te bouwen op jou manier. bij een abstracte klasse moet je dan bijv 100 huizen bouwen met dezelfde kleur..
Toevoeging op 17/01/2013 22:31:44:
@nicky zou je een beetje op je taal kunnen letten?
Erwin bevestigd hiermee mijn verhaal wat betreft interface en breid het zelfs veder uit.
Zijn er nog nog meer op of aanmerkingen, if kan ik hier dan wel mee uit de voeten?
@Reshad; ah zo had ik het niet begrepen vanuit de oop beginners handleiding van Joren
Gewijzigd op 17/01/2013 22:38:50 door Milo S
Quote:
Een interface stelt je in staat om aan te geven dat een object een bepaalde functionaliteit moet bezitten, maar het bepaalt niet hoe het object dat moet doen. De child class is dus vrij om de hele implementatie te doen, zolang hij maar voldoet aan de functionaliteit die de interface afdwingt.
en hij somt ook de belangrijkste verschillen
Quote:
Abstract classes
Een abstract class kan bepaalde functionaliteit definiëren en de rest overlaten aan de child.
Een child kan de reeds gedefinieerde methods overschrijven, maar hoeft dat niet.
De child class moet een logische relatie hebben met de parent.
Een child kan maximaal een abstract class extenden.
Interfaces
Een interface kan geen functionalteit bevatten. Het is enkel een definitie van de methods die gebruikt moeten worden.
De child class moet alle methods uit de interface van functionaliteit voorzien.
Verschillende niet gerelateerde classes kunnen op een logische manier gegroepeerd worden door een interface.
Een child kan meerdere interfaces tegelijkertijd implementeren.
Een abstract class kan bepaalde functionaliteit definiëren en de rest overlaten aan de child.
Een child kan de reeds gedefinieerde methods overschrijven, maar hoeft dat niet.
De child class moet een logische relatie hebben met de parent.
Een child kan maximaal een abstract class extenden.
Interfaces
Een interface kan geen functionalteit bevatten. Het is enkel een definitie van de methods die gebruikt moeten worden.
De child class moet alle methods uit de interface van functionaliteit voorzien.
Verschillende niet gerelateerde classes kunnen op een logische manier gegroepeerd worden door een interface.
Een child kan meerdere interfaces tegelijkertijd implementeren.
Maar we hebben het nu constant over de interfaces, maar ik vraag me ook af of iemand zou kunnen bevestigen dat derest van de logica goed zit?
Milo, plaats liever niet hier. Misschien wel even uitwerken in een UML diagram en die hier plaatsen of even een pastbin aanmaken ofzo.
Ik zal zodra ik thuis ben kijken of ik een UML diagram kan maken. Dan upload ik die ook wel
Toevoeging op 18/01/2013 19:38:50:
Ik heb hem maar even gewoon getekend op de computer. Bekijk hier het resultaat.
Volgens mij hoef je hier een constructor alleen niet in een interface te zetten. dat is weer een voorbeeldje waarbij je een abstracte klasse kan maken. ( als je alleen de constructor mee geeft om iets te doen ) en deze extenden met zijn eigen methods.
idem dito voor de Customer.
Voor de UserMapper zou ik juist een interface gebruiken om de CRUD methods vast te leggen. ( Create, Read, Update en Delete )
idem dito bij de image mapper
en wat is Database een klasse of een interface?