passero zei:
ik stel me eigenlijk ook de vraag wat men deed voor OO en design patterns...
procedurele talen zijn er toch altijd al geweest en ik kan me moeilijk voorstellen dat daar geen "theoriën" rond zijn om deftig code te schrijven. Ik heb een OO opleiding genoten, volledig in java waardoor (ik geef dat gerust toe) niet echt rendabele code schrijf in een strict procedurele omgeving.
er moeten daar toch ook richtlijnen ofzo rond zijn om herbruikbaarheid te stimuleren. Ik kan me dat moeilijk voorstellen dat in al die jaren van development niemand zo iets bedacht of uitgewerkt heeft en omgezet in boek of cursus ofzo....
Je moet rekening houden met het feit dat OO al langer bestaat als je denkt. OO wert in de jaren 80 uitgevonden, Design patterns maakten hun intrede met GoF in 1994. Al langer dan de meeste mensen denken dus.
De reden dat beide concepten ontstaan zijn is juist wat jouw probleem is: men kwam met slecht gestructureerde programma's die veel aanpassingswerk & weinig herbruikbaarheid als voornaamste slechte kenmerken hadden.
De voornaamste reden waarom ze dit in het begin niet nodig hadden was dat men toen toekwam met eerst de basis modulaire technieken (enkele functies) en daarna de uitgebreidere modulaire technieken dmv bijvoorbeeld structs. Toen die niet meer voldeden en het een vrij grote chaos werd bij grote projecten schakelde men stilaan over naar OOP. Maar vergis u niet: procedurele talen bleven op sommige vlakken nog zeer persistent, Quake 3 bijvoorbeeld werd nog volledig in c ipv c++ geschreven, terwijl dat al goed eind jaren 90 was.
Tyfius zei:
In niet object geörienteerde talen zoals bijvoorbeeld C gaat men eerder modulair werken en wordt er zeer veel gebruik gemaakt van structs. Op die manier kan men toch een beetje het object geörienteerde van talen zoals C++, Java en C# benaderen.
Kijk op SourceForge eens naar API's en frameworks die in C werden ontwikkeld om een beter beeld te krijgen.
Het modulair programmeren vind ik voor kleinere api's en libs vaak zelfs een betere aanpak. Je kan deze c-modulariteit mooi doortrekken naar c++ voor "mooiere" code, maar meer ook niet zonder gebruik te maken van alle design patterns e.d.
Het gevaar met alle oo-opties en designpatterns en dergelijke is dat je zéér snel tot overdesign kan komen. Dat is iets wat je bij eenvoudig modulair programmeren minder snel zal tegenkomen.
Ook zijn patterns op sommige levels overroepen. Ik deed sommige zaken die mensen een "pattern" noemen automatisch voor ik nog maar van design patterns gehoord had. Sommige zogenaamde patterns komen voornamelijk aan op je gezond verstand gebruiken.
Vich zei:
[edit] Maar het komt er op neer dat je een compound/struct maakt en een reeks functies. Die struct bevat dan al je klassemembers en wordt aan elke functie meegegeven. Zoiets:
Code:
struct List
{
ListItem* mBegin;
ListItem* mEnd;
};
void List_Add(IntList*&ioList, Item inItem)
{
...
}
void List_Clear(IntList& ioList)
{
...
}
void List_Add(IntList& ioList, Item inItem)
{
...
}
Ziedaar, een soort van klasse
Uiteindelijk zal zelfs een klasse naar dergelijke code worden omgezet (toch in C++). Overerving, afscherming, constructors, ... zijn allemaal "specialiteiten" die zich eigenlijk enkel op compiler niveau afspelen, op machinetaal niveau bestaat dit helemaal niet. Je methoden zullen dus in machinetaal omgezet worden naar gewone functies die als argument het adres van je klassevariabelen zullen krijgen.
