[UML] Nadelen Object Geöriënteerd Programmeren

[J.Hollemans]

We hebben op school het vak UML en daar wordt in het boek de verschillen tussen functie geöriënteerde en object geörienteerde programmeertalen "uitgelegd":

Functie:
-moeilijk te wijzigen sub-functies
Object geöriënteerd:
-werkelijkheid in kaart
-Implementatie onafhankelijk van de gevraagde functionaliteit
-Wijzigingen zijn makkelijk

kortom, alleen nadelen bij de ene en alleen voordelen bij het object geöriënteerde programmeren...

Vraag om een beetje een objectiever beeld te krijgen:
Wat zijn de voordelen van fuctie geöriënteerd programmeren tegenover de nadelen van object geöriënteerd programmeren ?

[Crysania]

ik heb ook UML geleerd, maar ik heb altijd OO gebruikt, het is logisch en goed dus waarom zou je anders doen??

wij kregen ook alleen UML in verband met OO
dat vak heette "OOA" Object geOrienteerde Analyse dus ik heb weinig verstand van functie georienteerde zooi

[Verwijderd]

Het enige (grote) nadeel van OO t.o.v. FO is dat het ontwerp-traject over het algemeen langer duurt.

[Verwijderd]

Jeroen,

Onderstaande link wijst naar een kritisch essay over OOP:

http://www.geocities.com/tablizer/oopbad.htm

Met betrekking tot de voordelen van "functie georienteerd"
programmeren, ik weet niet of je daarmee imperatief (bijv. Pascal, C) of functioneel (bijv. Scheme, Haskell) programmeren bedoelt.

Vriendelijke groet.

[chem]

langer - maar transparanter.

Met name het voortraject wordt vaak te snel begonnen en dan kost dat je achteraf tijd. Maar nix mis met UML of OOP hoor...

[J.Hollemans]

petrabbit:
Met betrekking tot de voordelen van "functie georienteerd"
programmeren, ik weet niet of je daarmee imperatief (bijv. Pascal, C) of functioneel (bijv. Scheme, Haskell) programmeren bedoelt.

Tnx voor de link en ik heb het over programma structuur, onafhankelijk van de programmeertaal die gebruikt wordt.

[mbravenboer]

Functie georienteerd programmeren? Merkwaardig gekozen naam. Als ik het goed begrijp wordt hier niet functioneel programmeren bedoeld. Ik ga dus maar uit van procedureel programmeren.

Algemen nadelen van OO-talen:
-----------
1. Syntax is vaak niet erg compact. Je moet er al snel behoorlijke lappen tekst tikken voor een klein probleem. Dit nadeel telt vooral ten opzicht van meer declaratieve talen zoals functionele (Haskell bijvoorbeeld), waar je vaak uitermate compact problemen kan beschrijven.

2. In een strakke OO taal, die geen andere faciliteiten biedt (zoals Java) is het vaak niet mogelijk om zaken makkelijk en netjes via een ander paradigma op te lossen. Strikt genomen is dat natuurlijk geen nadeel van OO.

3. Garbage Collection gaat een serieus probleem worden als dat niet wordt geleverd door de compiler of de run-time.

4. Bij OO-programma's is het vaak niet erg zichtbaar wat de consequenties zijn van een stuk code voor gegeheugengebruik.

5. OO-talen hebben vaak problemen met primitieve typen versus objecten. Java is daarvan een heel goed voorbeeld.

Maar uiteraard zijn er ook enorm veel voordelen, waardoor OO toch een heel aantrekkelijk paradigma is .

[mbravenboer]

JeroenHollemans: Tnx voor de link en ik heb het over programma structuur, onafhankelijk van de programmeertaal die gebruikt wordt.

Procedureel programmeren versus functioneel programmeren is toch een behoorlijk fundamenteel verschil (ook qua structuur). Het is wel noodzakelijk om hier onderscheid tussen te maken...

[Hillie]

Op dinsdag 13 november 2001 14:46 schreef ManiaXe het volgende:
Het enige (grote) nadeel van OO t.o.v. FO is dat het ontwerp-traject over het algemeen langer duurt.

Maar het voordeel van een langer ontwerptraject is wel dat het ontwerp duidelijker is en knelpunten sneller gevonden worden. En zeg nou zelf: ben je liever langer bezig met ontwerpen, of debuggen?

[mbravenboer]

Uit de link:

Some argue that OOP is still important even if not dealing directly with GUI's. In my opinion, much of the hype about OOP is faddish. OOP in itself does NOT allow programs to do things that they could not do before. OOP is more of a program organizational philosophy rather than a set of new external solutions or operations

Mwah, is dat een nadeel van OO?

Zo kan ik nog wel even doorgaan. Het artikel behandelt eigenlijk vrijwel geen technische aspecten van OO en gaat alleen maar over de nadelen van de hype eromheen. Ook gaan veel punten over een specifieke (onhandige) manier van gebruik van OO.

[Hillie]

Op dinsdag 13 november 2001 15:07 schreef mbravenboer het volgende:
Algemen nadelen van OO-talen:
-----------
1. Syntax is vaak niet erg compact. Je moet er al snel behoorlijke lappen tekst tikken voor een klein probleem. Dit nadeel telt vooral ten opzicht van meer declaratieve talen zoals functionele (Haskell bijvoorbeeld), waar je vaak uitermate compact problemen kan beschrijven.

Zeker waar. Maar op zich vind ik het vaak net ff wat duidelijker leesbaar dan een obscuur klein stukje programmatuur wat in onleesbare termen een hoop functionaliteit bevat. Niks ten nadele van functionele talen overigens hoor.

2. In een strakke OO taal, die geen andere faciliteiten biedt (zoals Java) is het vaak niet mogelijk om zaken makkelijk en netjes via een ander paradigma op te lossen. Strikt genomen is dat natuurlijk geen nadeel van OO.

Dit 'dwingt' je wel om dingen langs de 'nette' OO-manier op te lossen.

3. Garbage Collection gaat een serieus probleem worden als dat niet wordt geleverd door de compiler of de run-time.

Dat is een extra zorg voor de programmeur. Weer een reden om duidelijk gestructureerd te werk te gaan. Dan word je eigenlijk weer gedwongen om bij declaratie van (bijvoorbeeld in C++) dynamische structuren na te denken over het vrijgeven daar weer van.

4. Bij OO-programma's is het vaak niet erg zichtbaar wat de consequenties zijn van een stuk code voor gegeheugengebruik.

Da's waar, zeker als je geen kennis hebt over de implementatie van de objecten.

5. OO-talen hebben vaak problemen met primitieve typen versus objecten. Java is daarvan een heel goed voorbeeld.

Ook waar. In Java moet je soms aardig wat grappige acties uithalen om relatief eenvoudige type-conversie te doen.

Maar uiteraard zijn er ook enorm veel voordelen, waardoor OO toch een heel aantrekkelijk paradigma is .

Gelukkig maar! Ik heb OO "leren" programmeren in Modula-2 (een of andere beroerde OO-uitbreiding). Dat blonk niet uit in duidelijkheid, ook het onderwijs niet. Toen zelf Java maar opgepakt, boekje erbij waarin de concepten duidelijk vertaald werden naar programmacode. Dat scheelde enorm. Ik ben nu een groot fan van OO geworden!

[mbravenboer]

Hillie: Zeker waar. Maar op zich vind ik het vaak net ff wat duidelijker leesbaar dan een obscuur klein stukje programmatuur wat in onleesbare termen een hoop functionaliteit bevat. Niks ten nadele van functionele talen overigens hoor.

Functionele talen zijn inderdaad niet erg toegankelijk . De compactheid wordt echter niet alleen veroorzaakt door de compacte syntax met obscure constructries... Het paradigma zelf abstraheert van (voor sommige problemen) irrelevante details... Maar behalve dit wat obscure voorbeeld zijn er natuurlijk nog veel meer declaratieve talen te noemen die in voor bepaalde problemen ver te verkiezen zijn boven general-purpose OO...

Dit 'dwingt' je wel om dingen langs de 'nette' OO-manier op te lossen.

Tja, maar toch blijft het zo dat OO geen oplossing voor elk probleem is en zeker niet altijd de netste...

Ik ben nu een groot fan van OO geworden!

Ik ook wel hoor .

[Verwijderd]

Op dinsdag 13 november 2001 15:01 schreef JeroenHollemans het volgende:

[..]

Tnx voor de link en ik heb het over programma structuur, onafhankelijk van de programmeertaal die gebruikt wordt.

Juistem, de meeste programmeertalen zijn ge-ent op een bepaalde stijl, hetgeen implementaties van die talen in staat stelt om zinvolle(re) analyses van de code te doen.

Je kunt bijv. wel OO in C programmeren, maar de compiler zal je daar dan niet (extra) bij kunnen helpen.

Mijn (impliciete) vraag heb je daarmee niet beantwoord, omdat imperatief en functioneel programmeren nu juist stijlen zijn.

Ten opzichte van het 'oude' imperatief gestructureerd programmeren stelt OO meer specificatie en daarmee ontkoppeling verplicht.

OOP wordt daarom geschikt geacht voor bijvoorbeeld business applicaties, waar die specificatie mogelijk is (omdat je weet wat je gaat doen) en veel waarde wordt gehecht aan projectbeheersing.

Functioneel programmeren heeft hele goede resultaten geboekt aan precies de andere kant van het spectrum: het 'moving target' werk zoals dat bij bijv. AI onderzoek gebruikelijk is.

Al met al moet je het goede gereedschap voor de klus kiezen.

Ik vind het persoonlijk jammer dat OOP momenteel zo dominant is, en jij dit soort eenzijdige informatie op een serieuze opleiding gepresenteerd krijgt.

[Verwijderd]

Op dinsdag 13 november 2001 15:13 schreef mbravenboer het volgende:
Uit de link:
[..]

Mwah, is dat een nadeel van OO?

Zo kan ik nog wel even doorgaan. Het artikel behandelt eigenlijk vrijwel geen technische aspecten van OO en gaat alleen maar over de nadelen van de hype eromheen. Ook gaan veel punten over een specifieke (onhandige) manier van gebruik van OO.

Topmind zegt altijd dat hij aan wil tonen dat OO niet beter is dan de (door hem verkozen) stijlen die door OO in significante mate zijn verdrongen.

Het essay is al oud (minus recente updates), maar de goede man is nog steeds aan het brullen op comp.object.

Ik heb deze link gepost omdat ik geen goed verhaal paraat heb over voordelen van de procedurele stijl, en een anti-OO essay me in de context van de oorspronkelijke vraag equivalent leek.

.. Is OO in essentie uberhaupt technisch?

[Hillie]

Op dinsdag 13 november 2001 15:21 schreef mbravenboer het volgende:
Functionele talen zijn inderdaad niet erg toegankelijk . De compactheid wordt echter niet alleen veroorzaakt door de compacte syntax met obscure constructries... Het paradigma zelf abstraheert van (voor sommige problemen) irrelevante details... Maar behalve dit wat obscure voorbeeld zijn er natuurlijk nog veel meer declaratieve talen te noemen die in voor bepaalde problemen ver te verkiezen zijn boven general-purpose OO...

Dat is natuurlijk wel vaker zo. Maar ik moet zeggen dat ik C++ een erg mooie tussenoplossing vind. Weliswaar niet functioneel, maar je kunt zowel behoorlijk abstract OO te werk gaan, als hardcore ASM ertussen gooien.

Tja, maar toch blijft het zo dat OO geen oplossing voor elk probleem is en zeker niet altijd de netste...

Tja, sommige marketing-idioten willen dat natuurlijk nog wel eens verklaren, maar dat is bij geen enkele taal zo. Funtioneel heeft bepaalde mooie eigenschappen, imperatief ook, OO ook, ga zo maar door. Geen enkele taal is echter de 'perfecte' taal voor alles.

[Verwijderd]

Beide hebben gewoon voor- en nadelen, denk ik...
Ik werk nu al zo lang met Delphi dat 't bijna een 2e natuur is geworden om in objecten en objectstructuren te ontwikkelen, maar een paar maanden terug kreeg ik code te zien van een nieuwe collega, en die had met (open) arrays en pointers een structuur in elkaar gezet die zowel elegant als efficient was, en ook nog een aardig stuk sneller dan mijn aanpak.

Pas toen 't moest worden aangepast op een andere database benadering (ADO ipv BDE, MSSQL ipv InterBase), bleken echt de voordelen van een OO-aanpak: wanneer je uitgaat van abstract classes waar je de echte implementatie van afleidt, hoef je alleen maar op de technische details de subclasses aanpassen. Bij arrays, records en pointers moet je dan vaak hele stukken herschrijven...

[The - DDD]

OO en functioneel hebben beiden hun toepassingen.

OO is naar mijn idee vooral geschikt voor dynamische systemen. Veel verschillende toestanden en continu veranderende input en output.

Functioneel is juist uitermate geschikt om grote massa's data te verwerken.

Bovenstaande geld natuurlijk niet altijd, maar wat wel een goed voorbeeld is, staat ook in die ene link hierboven, is dat je soms helemaal niet wil hebben dat je code aan je data gekoppeld is. Tja dan ben je snel klaar met OO.

Beide manieren hebben voor en nadelen. Probleem is alleen dat de achterliggende gedachte dusdanig verschillend is, dat het lastig blijkt om snel van paradigma te kunnen wisselen zonder alsmaar weer lang te moeten 'wennen'.

Ikzelf kies OO boven functioneel omdat het op mij overkomt als een natuurlijkere denkwijze. Daarnaast kun je je problemen makkelijker opsplitsen in afgebakende gebieden. (iets wat ook met functioneel kan)


Feit blijft dat het netto eind resultaat in weze gelijk is, machine instructies.

[J.Hollemans]

Op dinsdag 13 novemberschreef petrabbit:
Ik vind het persoonlijk jammer dat OOP momenteel zo dominant is, en jij dit soort eenzijdige informatie op een serieuze opleiding gepresenteerd krijgt.

Volledig mee eens !
Vandaar dit forum !

Ik hou er niet van om zaken van 1 kant te horen, dat is op het MBO al te veel gebeurd met M*cr*s*ft en CMG gebeurd...

Dit topic heb ik gestart, om meer objectievere informatie te krijgen betreft dit onderwerp en dat lijkt me wel gelukt

Allemaal hartelijk bedankt !

[Verwijderd]

Maar het voordeel van een langer ontwerptraject is wel dat het ontwerp duidelijker is en knelpunten sneller gevonden worden. En zeg nou zelf: ben je liever langer bezig met ontwerpen, of debuggen?

Helemaal mee eens. Ik Probeer absolutte niet FO te prijzen, het was simpelweg het enige nadeel van OO t.o.v. wat ik zo snel kon bedenken...

[vinnux]

Op dinsdag 13 november 2001 15:07 schreef mbravenboer het volgende:

Algemen nadelen van OO-talen:
-----------
1. Syntax is vaak niet erg compact. Je moet er al snel behoorlijke lappen tekst tikken voor een klein probleem. Dit nadeel telt vooral ten opzicht van meer declaratieve talen zoals functionele (Haskell bijvoorbeeld), waar je vaak uitermate compact problemen kan beschrijven.

In eerste instantie moet je meer coderen, maar daar tegenover staat dat hergebruik dit "probleem" ruimschoots compenseert en uiteindelijk zelfs minder tijd kost om een groot sytsteem te maken ten opzichte van functionele talen.

2. In een strakke OO taal, die geen andere faciliteiten biedt (zoals Java) is het vaak niet mogelijk om zaken makkelijk en netjes via een ander paradigma op te lossen. Strikt genomen is dat natuurlijk geen nadeel van OO.

Zekers

3. Garbage Collection gaat een serieus probleem worden als dat niet wordt geleverd door de compiler of de run-time.

Zeker, maar zonder gc wordt het dan wel meer een realtime process, terwijl de gc een process non-realtime kan maken.
Dit is inderdaad een probleem bij bv Java. Het is moeilijk om realtime processen te maken, omdat je geen controle hebt over de gc. Volgens mij kun je in Ada 95 wel de gc controleren, maar hier heb ik mezelf niet in verdiept

4. Bij OO-programma's is het vaak niet erg zichtbaar wat de consequenties zijn van een stuk code voor gegeheugengebruik.

Zekers, maar eigenlijk wil je dat al OO er niks vanaf weten, omdat je he richt op modelring en niet op de consequenties voor de hardware. Dit wordt pas interessant als je realtime zaken wil doen.

5. OO-talen hebben vaak problemen met primitieve typen versus objecten. Java is daarvan een heel goed voorbeeld.

Zekers , deze kun je best weglaten en vervangen door object, maar iedereen is er zo gewend aan dat niemand meer de taal zou gebruiken, zoals SmalTalk (geloof ik)


En ik heb een erg groot nadeel van OO, mensen die overschakelen van functioneel naar OO hebben het vaak heel erg moeilijk om niet gelijk naar oplossingen en technische problemen te kijken.

Maar OO heeft de toekomst, alleen moet de performense nog omhoog.

Java is een heel erg mooi experiment met OO !

CU

[GiLuX]

maar zoals de auteur van dat artikel als een van de eerste dingen zegt, dat je met OOP veel langer bezig bent met het ontwikkelen van een programma, dat klopt zeker.
een van zijn argumenten is dat in real life daar eigenlijk niet echt rekening wordt gehouden maar dat het uit eindelijk wel om real life gaat.

als jij voor een klant iets gaat maken wat je een half jaar gaat kosten met OOP en de concurent het zelfde resultaat kan afleveren in de helft van de tijd kan je lullen als brugman tegen je klant dat jij het in OO doet en de concurent niet maar de, in 99% van de gevallen, niet technische klant begrijpt geen snars van waar je het over hebt en gaat voor de oplossing van de concurent.

dat is eigenlijk zijn grootste punt.

en ik ben het daar zeker wel mee eens.

uiteindelijk moet er wel geld mee worden verdiend,
hoe mooi je het ook vindt.

[Hillie]

Op donderdag 15 november 2001 09:39 schreef vgouw het volgende:
Maar OO heeft de toekomst, alleen moet de performense nog omhoog.

Je wilde me toch niet vertellen dat je C++ een slechte performance vindt hebben? Ook een OO-taal, maar wel met een aardig optimale vertaling van code naar machine-code.

[Hillie]

Op donderdag 15 november 2001 11:11 schreef GiLuX het volgende:
als jij voor een klant iets gaat maken wat je een half jaar gaat kosten met OOP en de concurent het zelfde resultaat kan afleveren in de helft van de tijd kan je lullen als brugman tegen je klant dat jij het in OO doet en de concurent niet maar de, in 99% van de gevallen, niet technische klant begrijpt geen snars van waar je het over hebt en gaat voor de oplossing van de concurent.

Voordeel van OO: Als je al eens zoiets gedaan hebt, dan kun je een hele berg klasses uit de kast trekken en zo iets nieuws implementeren. Dus voor herbruikbaarheid/maintenance (ook voor de klant zelf) is het wel weer een pluspunt OO te gebruiken.

[Crazy D]

Op donderdag 15 november 2001 11:22 schreef Hillie het volgende:
Voordeel van OO: Als je al eens zoiets gedaan hebt, dan kun je een hele berg klasses uit de kast trekken en zo iets nieuws implementeren. Dus voor herbruikbaarheid/maintenance (ook voor de klant zelf) is het wel weer een pluspunt OO te gebruiken.

Ja maar dat intresseert de klant ook niet zo veel. Naja, wel als hij daardoor sneller z'n programma heeft, maar t zal die klant worst wezen hoe je aan het eindprodukt komt. En dus is het de eerste keer, waarbij je de classes schrijft, langere ontwikkeltijd, duurder, en dus minder intressant voor veel klanten. En veel klanten denken niet na over de toekomst, waarbij er misschien wat aangepast moet gaan worden (vaak iets wat je nu absoluut niet kan inschatten) dus ook dat zal de klant worst wezen.
Maar ik vind dat je gelijk hebt

Naja, vaak dan. Gelukkig zijn er wel klanten die ook wat ruimer denken, en ook wel snappen dat als ze nu iets kopen, dat geen 100 jaar mee gaat en er ongetwijfeld in de toekomst wel aanpassing nodig zijn (en dat zijn ook de leukere klanten ).

[Verwijderd]

De meeste klanten vinden dit nou net wel belangrijk.
Vooral als er inhouse beheerd wordt.

[Creepy]

OO heeft de toekomst? Daarmee bedoel je ALLEEN OO?

OO heeft OOK de toekomst (en dan voornamelijk voor het maken van grote applicaties IMHO). Voor bijv. het schrijven van drivers pak je toch echt geen OO lijkt me.

[GiLuX]

Op donderdag 15 november 2001 11:22 schreef Hillie het volgende:

[..]

Voordeel van OO: Als je al eens zoiets gedaan hebt, dan kun je een hele berg klasses uit de kast trekken en zo iets nieuws implementeren. Dus voor herbruikbaarheid/maintenance (ook voor de klant zelf) is het wel weer een pluspunt OO te gebruiken.

en waarom zou dat niet kunnen met andere methodes?

net alsof reusability een feature van OOP is

als je alleen maar met losse functies werkt kunnen die ook heel goed reusable zijn.

maw,
je doet er in eerste instatie een stuk langer over maar het gevolg is dat het later tijd winst opleverd,
dat is niet juist,
wat hier uit volgt moet zijn: minder tijds verlies.

maar mischien is het voor de discussie beter als er eerst duidelijk wordt gedefinieerd wat OOP is.

als je een classje bouwt ben je dan al aan het OO programmeren?

ik heb het idee dat het pas begint als je echt design patterns met facades,factories e.d. in je model integreerd na eerst eens lekker rond de tafel te hebben gezeten om een paar rondes DSDM oid te doen.

het voortraject kan mischien alleen al een 1/4 deel van het hele traject kosten.

maar goed dan heb je ook wat.

punt is dan ook eigenlijk dat het op deze manier alleen zinvol is als je echt hele grote en complexe projecten doet om nog maar even op dat artikel voort te borduren.

en dat reusability dan voordelig, tja, natuurlijk maar er is dan geen alternatief dus is die reusability eigenlijk niet meer voordelig omdat het simpel weg niet te toetsen valt aan een alternatief.

[The - DDD]

Design patterns ruleren zwaar....

Ze maken een groot systeem opdeelbaar in afgebakende deelsystemen en dat is ook een van de krachten van OO.

Neem nou Java. Dat draait in weze op elk platform waar je maar een VM voor beschikbaar hebt. En wat is het verschil tussen al deze inplementaties? Juist de VM en ALLEEN de sun classes. De rest van de api is daarbovenop gebouwd en kan dus overal ingezet worden.

Als je een extreem voorbeeld van goed OO ontwerp wil zien, dan moet je naar Java's implementatie kijken. Hoe meer ik er mee werk, hoe meer respect ik ervoor begin te krijgen.

Als je het boek Design Patterns van de Gamma, Helm, Johnson en Vlissides er naast houdt zie je al die patterns terug in Java. Oh ja, het boek wat ik net noemde is sinds kort ook in een uitstekende nederlandse vertaling te krijgen. Zoek op "ontwerp patronen" op www.addison-wesley.nl en je vindt hem wel.

Als je een OO taal goed onder de knie hebt, dan is dit boek de volgende stap. (ookal is het gepubliceerd in 1995). Dat nederlandse boek is dus een vertaling van de engelse 1995 versie. (ik heb hier de engelse versie thuis, kijk even in e kaft, 22ste druk. *gloep* best-sellertje)

[mbravenboer]

GiLuX: en waarom zou dat niet kunnen met andere methodes?

net alsof reusability een feature van OOP is

Zeer mee eens, veel OO talen zijn juist vrij matig in generiek programmeren. Uiteraard kan je wel fraaie generieke designs maken op basis van interfaces, maar generieke functies over data-typen zijn vrijwel onmogelijk in de meeste OO-talen.

[mbravenboer]

The - DDD: Als je een extreem voorbeeld van goed OO ontwerp wil zien, dan moet je naar Java's implementatie kijken. Hoe meer ik er mee werk, hoe meer respect ik ervoor begin te krijgen.

De Java libs zijn inderdaad erg goed, maar ze zitten nog wel steeds vol met stomme design fouten. Een volledig nieuwe Java, waarbij nog beter nagedacht wordt bij het design van de libs zou wel mooi zijn . Weg met backwards-compatabillity (oid )

Als je design-patterns zou leuk vind, kan ik je nog een boek aanraden: Refactoring, improving the design of existing code van Martin Fowler. Dat zijn zo'n beetje de twee standaard-werken van dit moment op het gebied van OO-ontwerp .