Diskussion:Objektorientierte Programmierung

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Objektorientierte Programmierung“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

Archiv

Zur Archivübersicht
Wie wird ein Archiv angelegt?

Überarbeitung der Einleitung

Letzter Kommentar: vor 12 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt

Obwohl die Einleitung ihre jetzige Form bereits seit Jahren hat, enthält sie dennoch eine Falschinformation:

Die Grundidee dabei ist, Daten und Funktionen, die auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.

Das ist nicht die Grundidee von OOP, sondern die von ADTs, also abstrakten Datentypen. OOP setzt ADTs voraus, jedoch ist das eine nicht gleich dem anderen. ADTs werden in vielen Programmierparadigmen verwendet, nicht nur OOP, deswegen können ADTs in keiner Weise zur Definition von OOP dienen.

Es ist im Allgemeinen nicht völlig klar, was OOP exakt ist, da es bis heute (wie auch bei vielen anderen softwaretechnischen Begriffen) keine präzise Definition des Begriffs gibt. Es gibt nur einen gewissen "Minimalsatz" an Eigenschaften, über die sich alle einig sind, und die eine Programmiersprache mindestens erfüllen muss, um als objektorientiert zu gelten:

Dynamisches Dispatching, spätes Binden
Polymorphie
Klassen und Vererbung

Verschiedene Autoren formulieren das anders oder fügen weitere Eigenschaften hinzu, z.B. gibt es auch noch das berühmte "Message Passing", das insbesondere wesentlich für Smalltalk ist, aber in anderen OOP-Sprachen weniger Bedeutung hat. Auch der Begriff "Polymorphie" kann sich auf unterschiedliche Dinge beziehen: Mal ist er ein Synonym für dynamisches Dispatching (Subtyppolymorphie), dann wiederum bezieht er sich auf parametrische Polymorphie -- es ist alles sehr chaotisch.

Ich ändere jetzt die Einleitung, so dass sie ihrem Lemma ein wenig gerechter wird. Damit keine Missverständnisse aufkommen: Ich halte Laientauglichkeit für wichtig, jedoch darf sie nicht dadurch erkauft werden, dass man falsche Behauptungen auf- oder falsche Konnotationen herstellt. ʘχ (Diskussion) 21:59, 28. Mai 2013 (CEST)Beantworten

Deinem hehren Ziel der laientauglichen Qualität steht vor allem die Erwähnung der Ontologie der Anwendungsdomäne entgegen. --Melody Lavender (Diskussion) 08:33, 29. Mai 2013 (CEST)Beantworten

Das ist mir auch aufgefallen. Da muss man jetzt wieder abwägen: Wenn man versucht, den Begriff "Ontologie" zu entschärfen, muss man ihn entweder erklären -- eine Aufgabe, die nicht der Artikel "OOP", sondern der Artikel "Ontologie" hat -- oder umschreiben, was aber gefährlich ist, da das unter Umständen am Ende auch nicht besser verständlich ist und man vor lauter Laienverständlichkeit vielleicht nur noch schwafelt und nichts Konkretes mehr sagt.

Kennt denn jemand einen einfacheren, aber genauso exakten Begriff? ʘχ (Diskussion) 18:15, 29. Mai 2013 (CEST)Beantworten

Der Begriff Onthologie ist für mich wenig zielführend, weil er im Artikel keine prägnante Erklärung erfährt, die hier mehr aussagt als das Programmierdigma schon enthält, spielt also eine Rolle wie eine BKL, die dem Leser unscharf bekannte Hilfen zur Auffindung einer Erklärung bietet; die oben aufgezeigten Minimalbegriffe helfen mir mehr; die Methode der Erklärung durch Angabe notwendiger Bestandteile ist wesentlich günstiger als der Link auf den philosophischen Begriff Ontologie mit schwammiger Erklärung. --SonniWP✍ 19:59, 29. Mai 2013 (CEST)Beantworten

Ja, die genannten Bestandteile sind auf jeden Fall wichtig, und die sollten auch da stehenbleiben.

Was die Einleitung aber zusätzlich erklären sollte, ist, warum OOP eigentlich "objektorientiert" heißt und was die Denkweise/Philosophie dahinter ist. Also: Was sollen eigtl Klassen, Vererbung, Polymorphie? Wo kommt das her? Die Beantwortung dieser Fragen ist ja auch für einen Softwarearchitekten wichtig, weil sich daraus Hinweise ableiten lassen, wie man eine Ontologie aufbauen sollte und wie nicht. Jetzt ist die Frage, wie man diese Philosophie rüberbringt, ohne auf Begriffe wie "Ontologie" zurückzugreifen. Ich denke nochmal drüber nach. ʘχ (Diskussion) 21:37, 29. Mai 2013 (CEST)Beantworten

So ist Ontologie im WP-Artikel definiert:

' In der Ontologie geht es in einer allgemeinen Begriffsverwendung um Grundstrukturen der Wirklichkeit.'

' Grundstrukturen der Wirklichkeit' wäre allgemein verständlich. Also könnte man umformulieren:

Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen der Wirklichkeit der Anwendungsdomäne auszurichten.

oder noch weitergehend: Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen der Wirklichkeit, die durch die Anwendung abgebildet wird, auszurichten. Dafür wird in der Entwurfsphase ein Modell aufgestellt... --Melody Lavender (Diskussion) 07:39, 30. Mai 2013 (CEST)Beantworten

+1

Die Vokabel „Ontologie“ hat zumindest im Einleitungsabschnitt nichts zu suchen. Sie macht mehr Probleme als sie hilft. Wenn, dann im Rahmen eines späteren Abschnitts ausführlicher erarbeiten.
Das Wort „Objekt“ in „OOP“ meinte primär nicht irgendwas mit Bytes und Programmiersprache, sondern ein Dingsda in der Welt, aus der die Pizzaboten kommen. Die konkreten Gegenstände und abstrakten Konzepte in der Welt da draußen kennen auch gemeinsame Eigenschaften, Oberbegriffe, einzelne Instanzen. Das wusste man schon Jahrtausende vor der IT. OOP ist die Abbildung und Nachbildung der in der realen Welt sinnvollen Strukturen auf Objekte in der Programmiersprache. Dabei treten Konzepte wie Klasse und Vererbung und Polymorphie und Instanz an die Stelle von Kategorie und Oberbegriff und Gattung und Individuum. Je getreuer das Objekt im Computer hinsichtlich seiner Eigenschaften (und Methoden) den Verhältnissen der Anwendungswelt nachmodelliert wird, und je besser die Programmiersprache diese Übertragung unterstützt, desto besser klappt das.
Der Artikel Objektorientierung hat prinzipiell die gleiche Schwäche.

LG --PerfektesChaos 10:16, 30. Mai 2013 (CEST)Beantworten

Diverses

Letzter Kommentar: vor 9 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Als jemand, der sich inzwischen ein bisschen – nicht viel – in Java und Javascript hineingewurstelt hat und dabei oft vorab versucht hat zu verstehen, was die Objektorientierung bei Javascript bedeutet, muss ich sagen, dass ich finde, dass all die Definitionen, die hier für Objektorientierung oder objektorientierte Programmierung gebracht werden, für einen ahnungslosen Laien, der Nützliches erfahren will, ungeeignet sind. Die Definitionen hier sind eher intellektuelles Trimm-Dich für diejenigen, die es eh schon wissen und die dann untereinander schöne Dispute dazu führen und dabei zeigen können, was sie alles wissen. Das kann auch aklles richtig sein. Aber die Wikipedia ist nicht der Ort dafür. Man muss sein Zeug am Empfängerhorizont ausrichten.

Und manches, was auf der Seite geschrieben steht, erscheint mir obskur oder nichtssagend. Es heißt z. B.: „Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft“. Vorab sei schnell gefagt, was hier „Wirklichkeit“ ist. Wahrscheinlich ist doch irgendeine „Datenlandschaft“ gemeint, oder? Und eigentlich: Wenn die Ausrichtung auf relevante Umstände das unterscheidende Kennzeichen von Objektorientierung sein soll, was machen dann nicht-objektorientierte Programmierungen? Sind die nicht auf Strukturen relevanter Wirklichkeiten ausgerichtet? Das kann ja kaum sein. Ich frage mich auch, ob es gut ist zu schreiben: „Die einzelnen Bausteine, aus denen ein objektorientiertes Programm während seiner Abarbeitung besteht, werden als Objekte bezeichnet.“ Das klingt ja so, als ob Teile des Programmcodes die Objekte sind, um die es geht. Aber das ist doch nicht der Fall.

Soll man nicht wenigstens als eine konkrete Alternative oder Unterart etwas praktisch Hilfreiches anbieten, z.B. ungefähr wie nach der ++++-Zeile? Da werden jetzt Profis sagen, dass das von einem fast Ahnungslosen lächerlich an seinen umgrenzten HTML- und DOM- und JS-Erkenntnissen ausgerichtet ist. Das mag ja auch sein. Aber gegenüber diversem anderen Kauderwelsch (“Alles ist Objekt“ >> na super), den man auch beim besten Willen auch im Nachhinein teilweise nicht versteht, hätte mir das viel geholfen.

+++++++++++++++++++++++

In einem engen Sinn bedeutet objektorientierte Programmierung ooP, dass man Programme schreibt, die …

(1) … Datenstrukturen (Objekte), die schon für andere Automatismen geschaffen wurden und existieren, beeinflussen, weshalb man sich an diesen Strukturen orientieren muss (etwa: wie treffe ich das gewünschte Objekt, wie mache ich den gewünschten Einfluss auf das gewünschte Objekt geltend), wobei die Programme der ooP …

(2) … nicht immer alles selber machen müssen, weil es ja schon die anderen bereitstehende Automatismen gibt, die das, was die ooP für die Objekte bestimmt, ergänzen oder umsetzen.

Ein Beispiel dazu: Über Javascript wird auf einen Mausklick hin die Schriftgröße einiger Absätze einer Web-Site von 12px auf 14px geändert. Die Absätze sind die zu beeinflussenden Objekte, die nach bestimmten Regeln (HTML, CSS, DOM, …) schon vor meiner ooP definiert sind. Der Browser ist der bereitstehende Automatismus, der die Absätze nach den Regeln von HTML, CSS, DOM etc. anzeigt. Das Javascript-Progrämmchen ist eine ooP und ändert die vorliegenden Definitionen, indem sie die gewünschten Absätze anspricht und deren Schriftgröße von 12px auf 14px umdefiniert. Man orientiert sich an den Objekten, weil man wissen muss, wie man die gewünschten Absatz-Objekte selektiv anspricht und wie die Schriftgröße eines Absatz-Objekts definiert ist und wie man das ändern kann. Das konkrete Umsetzen der Änderung muss die ooP aber nicht selbst machen. Das macht der Browser als der bereitstehende Automat, wenn die ooP gesagt hat, dass es 14 px werden sollen.

(3) Darüber hinaus ist anzumerken, dass man mit ooP auch Objekte selbst definieren und erzeugen kann, die dann verwendet werden können, ggf. auch von den anderen Automatismen.

Wieder ein Beispiel dazu: Über Javascript kann man z. B. auf eine Nutzereingabe hin einen neuen Absatz einer web site erzeugen und ihn dann einfügen und vom Browser anzeigen lassen.

+++++++++++++++++++++++ (nicht signierter Beitrag von Axelpfeiffer (Diskussion | Beiträge) 22:27, 11. Jun. 2015 (CEST))Beantworten

Hi Axelpfeiffer! Schön dass du dich einbringst :-) Gleich mal vorweg: Bitte unterschreibe deine Beiträge mit --~~~~, dass wird dann in deinen Benutzernamen und das aktuelle Datum/Uhrzeit umgewandelt - vereinfacht die Diskussion. Bitte beginne auch einen neuen Abschnitt mit == Überschrift == (ich vermute du wolltest nicht an den vorhergehenden Abschnitt anknüpfen, der sich ja nur mit der Einleitung beschäftigt).

Zu deinen Punkten: Die Definition ist in diesem Artikel ein Problem. Es gibt unterschiedliche Ansichten was "Objektorientierte Programmierung" bedeutet - viele Leute werden sagen, dass JavaScript nicht objektorientiert sei, es gibt sogar Leute, die behaupten, dass nichtmal Java objektorientiert ist, da es ja auch Nicht-Objekte (z.B. Primitive oder Methoden) kennt. In Smalltalk z.B. ist tatsächlich alles ein Objekt: Die Zahl "2" ist ein Objekt, der Algorithmus "add" ist ein Objekt etc.

Darum konzentriert sich der Artikel und insbesondere die Einleitung nicht auf OO-Sprachen, sondern auf "Objektorientierte Programmierung". Und hier muss ich der Einleitung (ist nicht von mir) recht geben. Bei der OOP gehts darum die Wirklichkeit (nicht irgendwelche "Datenlandschaften", sondern die fachliche Aufgabenstellung des Programmes) zu modellieren. Und es ist genau so, wie du sagst, dass es nicht der Fall ist: Die Objekte (= Klassen und deren Attribute und Methoden) sind der Programmcode (und sonst je nach Programmiersprache mehr oder weniger nichts).

In nicht-objektorientierter Programmierungen gehts (je nach Sprachparadigma) um gänzlich andere Dinge, bzw. eine gänzlich andere Abbildung der "Wirklichkeit" - siehe z.B. Funktionale Programmierung oder Logische Programmierung

d.h. die Sätze, die du bemängelst sind zwar korrekt, könnten aber natürlich noch besser, einfacher, verständlicher, ... geschrieben werden.

Zu deinem Definitionsvorschlag: (1) ist falsch und kommt vermutlich daher, dass du mit JavaScript arbeitest. In anderen OO Sprachen werden sehr wohl hunderte oder tausende Klassen (neu) programmiert von denen es zur Laufzeit Instanzen gibt. Da gehts nur am Rande ums "wie treffe ich das gewünschte Objekt" (am Beginn einer Nicht-Web-Applikation ist z.B. kein fremdes Objekt vorhanden), sondern um die Programmierung der Klassen und deren Verlinkung untereinander (statisch zur Compilezeit und dynamisch zur Laufzeit).

(2) stimmt, ist aber keine Eigenschaft der Objektorientierung, sondern kommt durch die Einbindung von Libraries und Frameworks (die es auch für Nicht-OO-Sprachen gibt). Man kann auch OO-Programme schreiben (war in den 80er Jahren der Standard) ohne Libraries und Frameworks zu verwenden. Auch in JavaScript verwendest ja nichts anderes als eine Library/Framework, die dir die Arbeit am DOM-Baum und sonstiges erleichtert.

(3) Ja genau - das ist aber nicht "zu bemerken" - sondern die Quintessenz und 99,9% der Tätigkeit bei der OO-Programmierung

d.h. ja die Einleitung und andere Teile sollten verständlicher werden, aber nein - die stimmen schon (zumindest mehr als deine Vorschläge). --Sebastian.Dietrich ✉ 21:34, 12. Jun. 2015 (CEST)Beantworten

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hallo Sebastian Dietrich,

danke für die sehr interessante Antwort. Drei Fragen dazu:

1. Bin ich vielleicht meiner ungenauen Lesweise dahingehend, dass ich keinen Unterschied zwischen „Objektorientierte Programmierung“ und „Objektorientiere Programmiersprache“ gemacht habe, zum Opfer gefallen? Ich meinte, in dem Wikipedia-Artikel „Objektorientierte Programmierung“ die Erläuterung dafür gefunden zu haben, was gemeint ist, wenn Java/Script immer als „objektorientierte Programmiersprachen“ bezeichnet werden, dabei scheint der Artikel aber etwas ganz anderes zu betreffen, das ich nicht im mindesten verstehe. Wenn dem so ist, wäre es chic, in den ersten Zeilen des Artikels diese sprachlich kleinen, sachlich großen Unterschied zu klären und dann vielleicht auch eine Seite für „objektorientierte Programmiersprachen“ zu bringen. Ich nehme an, dass noch mehr Laien wie ich sich in diesem Dschungel verlaufen.

2. Richtig scheint zu sein, dass OOP Objekte generieren kann. Wenn es auch richtig ist, dass Programmteile Objekte sind, dann heißt das, dass objektorientierte Programmierung Programmteile (=Objekte) generiert. Was sagt uns das jetzt? Ist es mehr als eine trivial-nichtssagende Tautologie a la „Weise Farbe macht die Wand weis“ – oder noch trivialer, dass beim Programmieren Programme entstehen?

3. Im JavaScript-Artikel ist ein Link auf „Objektorientierte Porgrammierung“. Warum aber bei JavaScript Deiner obigen Aussage folgend Programmcodeteile Objekte sein sollen, erschließt sich mir nicht, und zwar nicht nur ein bisschen nicht, sondern überhaupt gar nicht. Das kann einerseits gerne meiner weitläufigen Ahnungslosigkeit geschuldet sein. Aber andererseits ist es ja gerade Sinn dieser Artikel, den Ahnungslosen eine Ahnung zu verschaffen, denn die brauchen es am Dringendsten.

Ich will hier niemanden quälen. Aber der Wikipedia-Artikel schafft es m. E. nicht, das Thema auch nur ansatzweise zu erläutern, selbst wenn man ihn aufmerksam liest und sich gutwillig damit beschäftigt. Mir scheint, dass das, was hier geschrieben ist, eher die hinterletzten Verästelungen des Labyrinths beschreibt, aber zu dem, was vorne am Eingang ist, nichts sagt. Die Autoren schreiben für Ihresgleichen. Das kann man gerne machen. Aber wenn darüber die Nicht-Ihresgleichen vergessen werden, dann ist aus einem Lexikoneintrag ein Fachartikel geworden. Der kann superrichtig sein. Aber die Wikipedia sollte jedenfalls AUCH etwas liefern, mit dem Laien etwas anfangen können.

--Axelpfeiffer (Diskussion) 22:01, 2. Jul. 2015 (CEST)Beantworten

Die Klasse "Auto"

Hi,

ich wollte nur kurz einen Gedanken zur Erklärung von Objektorientierung loswerden. Ich finde in Bezug auf Erklärung von Klassen diese typischen Autobeispiele schrecklich, weil sie jemandem, der funktional programmieren gelernt hat, in keinster Weise klar machen, was an Objektorientierung sinnvoll sein soll. Für nicht vorgeprägte Anfänger mag das Autobeispiel interessant sein, wenn aber jemand schon abstrakt denken gelernt hat, ist der konkrete Gegenstand "Auto" ehr hinderlich. Besser wäre, man erklärte es z.B. an Hand eines Kontos oder einer Datenbank.

Objektorientierung bedeutet imho nicht, Programmierung an der realen Welt zu orientieren, sondern Variablen und Funktionen sinnvoll und sicher zu gruppieren und den Zugriff darauf transparenter und einfacher zu machen.

Dietrich 12:21, 19. Jul. 2015 (CEST) (ohne Benutzername signierter Beitrag von 2A02:908:F610:5181:F6EC:38FF:FEAB:5671 (Diskussion | Beiträge))