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.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

Zur Archivübersicht

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 50 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Überarbeiten nötig : Objektorientierte Programmierung ist eine Stilfrage und erfordert nicht zwingend eine OOProgrammiersprache

Der Artikel stellt es so dar, als erfordere Objektorientierte Programmierung zwingend eine objektorientierte Programmiersprache. Das ist allerdings nicht der Fall. Prinzipiell kann man in vielen Programmiersprachen objektorientiert programmieren. Im einfachsten Fall (statische Methoden, keine Vererbung) reicht es aus wenn eine Programmiersprache Strukturen und Zeiger auf Strukturen unterstützt. Komplexere Sachen, wie Vererbung werden möglich sobald eine Programmiersprache Zeiger auf Prozeduren unterstützt. Also in C ist "manuelle" OOP definitv möglich (vieleicht nicht gerade übersichtlich). Grundsätzlich ist es logischerweise auch in Assembler möglich, denn was ein Compiler Produziert kann man grundsätzlich immer in Assembler ausdrücken(Was vor allem wichtig ist, ist das man Prozeduren hat, die den Speicher verwalten, also quasi neuen Objekten eine Position zuweisen(wobei das Datensegment dadurch auch quasi ein Objekt ist)). Wenn jemand Quellen will, im Handbuch von Turbo Assembler 3.0 ist es gut erklärt, wie OOP auf Assemblerebene aussieht (TASM 3.0 ist zwar selbst eine OOProgrammiersprache(womit sich Borland auch dauernt im Handbuch brüstet(wenn sie sich mal nicht damit brüsten, das sie besser als Microsoft sind[:-)])) jedoch ist da auch gut erklärt was die Direktiven letzendlich für Befehle produzieren). Unter Berücksichtigung dieser Tatsachen sollten auch Ausdrücke wie "nicht können" ind "nicht tun" umgewandelt werden (z.B. "auf die inneren Daten kann nur über Prozeduren zugegriffen werden" in "auf die inneren Daten wird nur über Prozeduren zugegriffen" umwandeln (denn bei manueller OOP ist es durchaus noch Möglich(Was in manchen Fällen sogar eine deutlich geringere Ausführungszeit benötigt(Probleme bei der Portierung kann man umgehen, indem man die Strucktur des Objekts per Header in das andere Programm einbindet, und bei Änderungen an der Klasse die Strucktur anpasst)))).

Vieleicht sollte auch noch erwänt werden dass Objekt-Dateien und Objekte in der OOP nicht nur zufällig den gleichen Namen haben, sondern durchaus einige Gemeinsamkeiten haben. Es kommt in der "normalen" Programmierung durchaus vor, dass man das Datensegment, in einer Quelldatei als "privat" deklariert (oder einfach keine Adressen darin "public" macht) und auch das gesamte Datensegment der Quelldatei nur über die Prozeduren zugreift(der Cache der Dateizugriffsfunktionen in Hochsprachen arbeitet z.B. so). In diesem Fall ist die daraus assemblierte/compilierte Objektdatei sogar ein Objekt im Sinne der OOP. (nicht signierter Beitrag von 79.210.53.245 (Diskussion) 22:07, 20. Jul 2012 (CEST))

Diese These ist falsch. Dass OO schlussendlich zu Maschinen- oder Bytecode wird heisst nicht, dass der daraus resultierende Code selbst objektorientiert ist. Dasselbe gilt auch für die Aussage, dass auf interne (private) Daten sehr wohl zugegriffen werden kann. Das ist nur mit nicht-OO Mitteln wie Introspection oder auf Maschinen- oder Bytecodeebene möglich.

Also zusammengefasst: OO ist nur mit OO Sprachen möglich. Aus OO Code wird (wie überall sonst auch) Maschinen- oder Bytecode. Derselbe Code kann auch anders erzeugt werden, ist aber selbst nicht mehr OO. --Sebastian.Dietrich ✉ 23:32, 20. Jul. 2012 (CEST)

C++ uä zeigen das Gegenteil: Man kann damit O-orientiert programmieren, wird aber nicht durch die Sprache dazu angeleitet. Es fehlt in diesen erstem Sprachen an der Förderung des objektorientierten Denkens; denn ein Paradigma ist zuerst eine Denkart, erst in zweiter Linie wird eine Implementierung mithilfe eines Laufzeitsystems benötigt. Der fehlende Erfolg von Smalltalk liegt so an der mangelnden Konkorrenzfähigkeit der Sprachimplementierung; Die von CalTech angebotene Implementierung zum Preis der Bücher implementierte zwar die Sprache, war aber zur Laufzeit nicht einfach beherrschbar, weil Zeitpunkte, zu denen garbage collection benötigt wurden nicht von außen bestimmt werden konnten und unkalkulierbar in den Tests auftraten. --SonniWP✍ 10:16, 28. Aug. 2012 (CEST)

Die These aber lautete "Objektorientierte Programmierung ist eine Stilfrage und erfordert nicht zwingend eine OOProgrammiersprache". Jetzt sprichst du davon, dass OO-Programmiersprachen nicht zu OO zwingen. Das ist korrekt, aber was gänzlich anderes & wird auch nirgendwo im Artikel behauptet. --Sebastian.Dietrich ✉ 17:49, 28. Aug. 2012 (CEST)

Ich bezog mich mehr auf den vorstehenden Beitrag; Grundsätzlich meine ich, dass eine OO-Sprache das Paradigma unterstützen sollte und sich dabei eben nicht nur Stilfragen stellen, sondern handfeste Strukturfragen durch "wohldefinierte gute Formen" gute Lösungen anbieten sollen und die Überarbeitung klar herausstellen sollte, was die OO-Sprachen dazu beitragen (können). --SonniWP✍ 18:06, 28. Aug. 2012 (CEST)

Klasse und Prototyp

Ein Unterschied wird aus der Beschreibung nicht ersichtlich. --SonniWP✍ 18:07, 27. Aug. 2012 (CEST)

Änderungen am Prototyp werden dynamisch am abgeleiteten Objekt wirksam, wägtrnd die Ablritimh rinrt Klasse statisch wirkt. --SonniWP✍ 20:15, 28. Aug. 2012 (CEST)

Überarbeitung der Einleitung

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)

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)

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)

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)

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)

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)

+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)

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.

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