Overleg:Objectgeoriënteerd

Beste,

Ik vind het codevoorbeeld niet echt geslaagd. Mijn eerste en laatste indruk er van is: "Een soepje van poëtische nederlandse termen en onoverzichtelijke verzonnen syntax."

Zou het niet beter zijn om terug te vallen op C++, Java, C#, ... of een andere bestaande taal? Bovendien zou een bijhorend UML diagram boekdelen spreken. Dat is overigens ook hoe het concept wordt uitgelegd in de vakliteratuur. Tenslotte draait OOP om structuur, niet om syntax, laat staan verzonnen syntax.

Het gebruik van accolades lijkt mij alvast een goed begin en voor de hand liggend.

Mag ik dit aanpassen?

Groeten Bram

Asjeblieft, doen, en anders doe ik het, want dit codevoorbeeld voegt naar mijn mening niet echt iets toe aan het artikel! Rickpastoor 4 mrt 2007 20:23 (CET)

Titel

Is er een reden waarom dit artikel "Objectoriëntatie" heet en niet "Objectgeoriënteerd"? Ik heb de term nog nooit zo horen gebruiken. Het Engelse artikel heet ook "Object-oriented" en het Duitse "Objektorientierte"; kortom, zoals je het gebruikt wanneer je er "programmeren" achter plakt. Volgens mij betekent objectoriëntatie ook niet helemaal hetzelfde. Een taal is niet objectoriënterend en objectoriënteert niet. De term "OOP" of "OO" staat nou eenmaal voor de Engelse term. Indien geen bezwaren hernoem ik het artikel. Anoko 10 jan 2008 01:01 (CET)

De reden was waarschijnlijk dat op Wikipedia bij voorkeur zelfstandige naamwoorden als titel gebruikt worden. De term bestaat in elk geval, en ik zou hem zelfs opnieuw verkiezen als titel. Riki 10 dec 2009 18:50 (CET)

De term "objectoriëntatie" betekent wat anders. Als je er een zelfstandig naamwoord bij wilt hebben moet het "Objectgeoriënteerde taal" of "Objectgeoriënteerd werken" o.i.d. worden, maar dan vind ik dit beter. "Objectgeoriënteerdheid" zou het juiste zelfstandige naamwoord zijn, maar vind ik ook niet beter. "Objectoriëntatie" is hoe je objecten neer zet, geen eigenschap van bv een programmeertaal. anoko

"Objectgeoriënteerd" is werkelijk één van de lelijkste woorden uit het vocabulaire van de ICT, en dat heeft er een aantal. Moet het niet gewoon "objectgericht" zijn? QVVERTYVS (hm?) 18 jun 2013 22:00 (CEST)

Het woord staat wel in Van Dale, dus het klopt wel. Lelijk of niet. --MichielDMN 🐘 (overleg) 18 jun 2013 22:25 (CEST)

Spijtig. QVVERTYVS (hm?) 23 aug 2013 11:00 (CEST)

De morfologie van een object

Kleuske, ik zie niet in wat de studie naar morfemen, dus de morfologie in de taalkundige zin, te maken heeft met de vormelijke kenmerken van een object in het kader van het objectgeorienteerde programmeren.

De morfologie in biologische zin is mijns inziens veel meer van toepassing aangezien dit type morfologie zich richt op de studie van uitwendige bouw en vorm van organismen. De analogie in het kader van het objectgeorienteerd programmeren is hierbij dat in het geval dat een object een instantie van bijvoorbeeld de klasse "mens" is, de attributen van dit object, bijvoorbeeld lengte, gewicht, haarkleur, geslacht, etc, overeenkomen met de vormelijke kenmerken van een mens in biologische zin. Het object is in beide contexten hetzelfde, namelijk mens, met dezelfde vormelijke eigenschappen.

Als je het hier niet mee eens bent hoor ik graag een betere vergelijking wat de toepassing van morfologie in taalkundige zin legitimeert. Nogmaals, ik zie niet in wat de attributen van een object te maken hebben met de bouw van woorden.

Ik vind beide vak-specifieke beschrijvingen, taalkundig en biologisch, eigenlijk totaal niet van toepassing... dit is toch zowel niet morfologie zoals gebruikt in de biologie en ook niet zoals in de taalkunde? Een oplossing als polymorfisme lijkt me de juiste: een aparte pagina voor morfologie zoals gebruikt in de informatica. Alternatief is om gewoon geen duur woord te gebruiken voor iets wat gewoon "vorm" betekent ;). anoko 19 nov 2008 15:13 (CET)

Zit wat in, ik heb overigens tijdens de opleiding altijd geleerd dat de attributen de 'toestand' van een object definieren, en niet een 'vorm'. Bij abstractere objecten is de term 'vorm' ook niet meer van toepassing denk ik, in ieder geval niet meer in ruimtelijke zin. Ricardo

Strikt genomen wordt de toestand van een object bepaald door de waarden die aan de attributen toegekend is en wordt de vorm van een klasse bepaald door de attributen die een klasse heeft. Hier is het artikel niet duidelijk in.

Het artikel gaat er ook, ten onrechte, van uit dat er bij objectgeorienteerd programmeren altijd sprake is van klassen, en dat deze klassen de vorm van de objecten bepalen. Dit is bij prototype-gebaseerde OO niet het geval: daar is helemaal geen sprake van klassen. En bij talen met ducktyping wordt de vorm van een object niet (exclusief) bepaald door de klasse waarvan het een instantie is. Kortom, het artikel laat m.i. nog wel wat te wensen over.

MrBlueSky 24 nov 2008 17:16 (CET)

Hoi MrBlueSky. Met je eerste opmerking ben ik het helemaal eens, ik heb dit iets beter geprobeerd te verwoorden. Wat betreft je twee opmerking; klasses zijn wel degelijk een fundamenteel concept in OO, lijkt me, en ik denk dat het OO concept ook zeker hiermee uitgelegd moet worden. Het niet meer expliciet hoeven te definieren van klasses zegt niet dat het klasseconcept daar niet in bestaat. Later in het artikel kan natuurlijk nog prima uitgelegd worden dat er ook vormen van OO zijn zonder volledige dan wel expliciete klassedefinities. anoko 26 nov 2008 00:55 (CET)

Je vergist je, anoko: er zijn wel degelijk talen en bibliotheken die object-georienteerd worden genoemd, en ook objecten en overerving kennen, mnaar geen klassen. Rp 19 nov 2010 13:53 (CET)

Overleg

Ik vind dit artikel nog echt niet goed genoeg. Zeker niet in vergelijking met het engelse artikel. --87.212.139.000 1 okt 2009 21:22 (CEST)

Mee eens. Twee dingen die ik zelf het eerst zou verbeteren:

• Het onderscheid en de relatie tussen objectgeoriënteerde gebruikersinterfaces en objectgeoriënteerde talen moeten beter worden uitgelegd.
• Klassenloze objectgeoriëntatie, zoals in JavaScript, moet een aparte sectie krijgen. Rp (overleg) 15 feb 2012 13:42 (CET)

"Orkestratie"?

Is het een idee om een verwijzing naar orchestration op te nemen? Een object kan uit zichzelf niets. Je verbindt ze met elkaar middels orkestratie (als de Nederlandse taal dat toelaat).

Ik zie het woord "orkestratie" in dit verband voor het eerst. Wordt niet simpelweg implementatie bedoeld (volgende op declaratie)? Of wordt op instantiatie gedoeld, die van klassen objecten maakt? Rbakels (overleg) 13 nov 2020 14:15 (CET)

Ik ook. Ik vermoed dat hier op een ander soort object wordt gedoeld. Rp (overleg) 13 nov 2020 16:25 (CET)

In het objectgeoriënteerd programmeren is dit niet waar: de orkestratie wordt uitgesplitst over methoden van objecten. (Dat dat niet zondermeer verstandig is, is een andere kwestie.) Rp (overleg) 15 feb 2012 13:38 (CET)

Het is verstandig om een sectie toe te voegen over de relatie tussen objecten in OO talen en de passieve, gedragsloze zogenaamde 'objecten' waar veel softwareontwikkelaars het vaak over hebben, die eigenlijk structs/records zijn, geen methoden hebben en hun data niet encapsuleren. Rp (overleg) 15 feb 2012 13:45 (CET)

Een C++ class met uitsluitend een "public" sectie en geen methods is equivalent aan een klassieke "struct". Dat dit geen "bona fide" object-georiënteerde manier van programmeren is, is iets anders. Rbakels (overleg) 23 apr 2012 10:04 (CEST)

Waar het mij om ging is dat het idee van objectgeorienteerd programmeren juist is dat objecten gedrag hebben, dus meer dan klassieke "struct"s zijn. Rp (overleg) 29 mrt 2016 02:06 (CEST)

"De meeste objectgeoriënteerde talen zijn gebaseerd op het klasse-concept."

Wellicht wordt niet altijd het woord "klasse" (of "class") gebruikt, maar ik dacht dat O.O. programmeren altijd werkt met een dergelijk concept, d.w.z. met een onderscheid tussen genus en species dat zelfs in de wijsbegeerte wordt toegepast: zeg maar het verschil tussen een stoel en de stoel. Het "genus" stoel duidt op een begrip (een bepaald soort zitmeubel) dat vervolgens geïnstantieerd kan worden tot de stoel waar ik op zit terwijl ik dit zit te typen.

Een C++ "class" statement begint de definitie van een genus: het definieert eigenschappen, maar verder is het nog niets. Op een stoel kun je zitten, maar niet op het begrip zelf.

Dat JavaScript "klasse(n)loos" zou (zie boven) zijn kan ik niet plaatsen. Wellicht is het misverstand dat niet altijd alle klassen door de gebruiker zelf behoeven te worden gedefinieerd, maar er ook "built-in" klassen kunnen zijn.

"Orkestreren" (zie boven) is hiervoor geen gebruikelijke en m.i. ook geen verhelderende aanduiding. "Instantiëren" is AFAIK het gangbare begrip. Rbakels (overleg) 23 apr 2012 09:59 (CEST)

JavaScript kent inderdaad geen klassen. Niet built-in en ook niet door de gebruiker gedefinieerd. Het maken van objecten gaat via functies. Functies die gebruikt worden om objecten te maken worden constructors genoemd en ieder object heeft een constructor. Het overerven gaat via prototypen: iedere functie heeft een prototype-object, en alle methodes en properties van het prototype-object van een functie worden geerfd door objecten die die functie als constructor hebben. Hier staat een uitleg met voorbeelden: [1]. MrBlueSky (overleg) 23 apr 2012 15:59 (CEST)

Ik heb de gewraakte zin vervangen door iets neutralers dat beter ondersteund wordt door de vakliteratuur. Oscar Zariski (overleg) 29 aug 2017 16:26 (CEST)

Er is nog het een en ander te verbeteren, maar voor ik dat probeer wil ik graag advies over het volgende.

De huidige versie van het artikel neemt op verschillende plekken nog steeds aan dat er altijd met klassen gewerkt wordt. Andere objectgeoriënteerde systemen en talen zijn zeldzaam, maar ze bestaan (b.v. JavaScript voor ECMAScript 6). Ik zie twee manieren om dit te verbeteren:

- Maak deelhoofdstukken: Klassengebaseerd en Niet-klassengebaseerd.

- Weef het door het hele artikel heen. Je moet dan steeds het gevalsonderscheid maken. Dit maakt de tekst onnodig omslachtig voor de meeste lezers, die waarschijnlijk toch alleen in klassengebaseerde OO geïnteresseerd is, en zal waarschijnlijk door toekomstige bewerkers, die dat alleen kennen, niet worden gerespecteerd.

Het eerste maar doen dan? Rp (overleg) 13 nov 2020 16:46 (CET)

Doe maar, je hebt mijn steun. Met vriendelijke groeten, 4ever_(Overleg) 15 nov 2020 10:13 (CET)

objectgeoriënteerd programmeerparadigma?

Programmeerparadigma meldt dat Objectgeoriënteerd geen programmeerparadigma is. – De voorgaande bijdrage werd geplaatst door 84.24.67.29 (overleg · bijdragen) PS: Wil je voortaan alsjeblieft op overlegpagina's ondertekenen met vier tildes (~~~~)? Er wordt dan automatisch een link naar je gebruikerspagina geplaatst.

Ik heb net het een en ander aangepast (inclusief bronnen) OekelWm _(Overleg) 2 aug 2013 03:17 (CEST)

Methoden

Ik zie niet in waarom in de sectie 'Concepten' de term 'methoden' tussen haakjes zou moeten staan. Madyno (overleg) 25 jan 2019 22:05 (CET)

Inderdaad, het nut is me ook niet duidelijk. Slaat zelfs nergens op: als je het deel tussen haken niet leest, is het geen zin meer. MichielDMN 🐘 (overleg) 25 jan 2019 22:07 (CET)

Het staat er al wel even in, zie ik: https://nl.wikipedia.org/w/index.php?title=Objectgeori%C3%ABnteerd&diff=29544282&oldid=29537737. MichielDMN 🐘 (overleg) 25 jan 2019 22:10 (CET)

Ik heb het veranderd. Madyno (overleg) 25 jan 2019 22:54 (CET)