Mijn god zeg, 'k kan 't niet meer aanzien, 'k moet me even mengen in de discussie en OO standpunten (voor zover ik heb gelezen van genoil) ondersteunen.

Alvast mijn excuses iig als het wat onsamenhangend overkomt, aangezien ik nogal gek aan het worden ben van de hoeveelheid discrete wiskunde dat ik vandaag door m'n strot heb gestouwd
Allereerst valt me op dat er zich hier veel mensen bevinden die erg veel waarde hechten aan een top down approach c.q. procedural methode van programmeren. Hier is natuurlijk niets mis mee als we praten over relatief kleine software systemen maken, maar bij (grote) software systemen bouwen of uitbreiden kan dit een bottleneck vormen in de zin dat onderhoudbaarheid significant kleiner wordt doordat complexiteit hier vrij snel de overhand in neemt; het model simpelweg opbreken in procedures volstaat hierbij niet alleen, als we alleen al redeneren vanuit een complexiteit standpunt. Aan deze mensen even een paar sleutelwoorden voor het modeleren vanuit een object oriented standpunt: abstraction en composition.
Bij composition en abstraction gaan we uit van een probleem die we willen modeleren. Dit doen we door het complexe probleem ( het overkoepelend model) op te breken in kleinere, begrijpbare submodellen (composition) die we reduceren tot een gunstige, begrijpbare vorm (abstraction). Bij composition en abstraction moeten we oppassen dat we niet tever hiermee in doorgaan, waardoor er teveel componenten ontstaan of componenten te moeilijk van elkaar te onderscheiden zijn.
Als je dit eenmaal bewerkstelligd hebt, kun je classen bouwen/(abstract) inherenten en hierdoor reeds geschreven code gebruiken danwel uitbreiden; dit staat in schel contrast met simpelweg alleen static calls uitvoeren. Dit scheelt regels code, verkleint complexiteit en indien goed geschreven kan het resulteren tot een betere peformance, maar uiteindelijk is de algoritme het meest bepalende factor voor performance en niet whitespaces e.d. Ook gebruik je slechts code die je ook daadwerkelijk nodig hebt.
Indien goed uitgevoerd zou de afweging performance - onderhoudbaarheid niet echt meer aan de orde moeten zijn

, en als je dan toch de afweging moet maken, kies dan voor onderhoudbaarheid; overcapaciteit voor performance kun je binnen 3 seconde aanschaffen itt code opnieuw van scratch opbouwen dat je ongetwijfeld veel tijd, moeite en tranen zal kosten. En ja, tijd is geld...

, dus de afweging zou duidelijk moeten zijn

. Goede documentatie draagt bij aan onderhoudbaarheid en dit is een GROOT voordeel als je met meerdere programmeurs aan een project werkt; hanteer hierbij allen dezelfde conventie (docstyle) zodat eenduidigheid bewerkstelligd kan worden. Duidelijke pre- en postcondities formuleren kan complexiteit ook tegengaan. Oh ja en voordat ik het vergeet, applicaties zijn zelden echt 'AF', hou rekening met de toekomst en kies onderhoudbaarheid; computerkracht wordt over tijd al steeds groter.
Een systeem bestaat over het algemeen (afhankelijk van de vereiste functionaliteit) uit minstens 3 lagen:
1. User Interface (Presentatielaag: Raampjes, weetikveel - Client)
2. Model (Codelaag: Classen etc.. - Server)
3. Data Management (Datalaag: Databasefile systeem)
Nahjah, 'k kan nog wel even doorgaan, maar 'k heb geen zin meer om te typen, 'k moet nog 500 pagina's discrete wiskunde inhalen

. Ik hoop dat iig dat het bruikbaar voor iemand kan zijn