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 wirksan, 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)