Diskussion:Objektorientierte Programmierung/Archiv/1

aus Wikipedia, der freien Enzyklopädie
< Diskussion:Objektorientierte Programmierung
Letzter Kommentar: vor 9 Jahren von Axelpfeiffer in Abschnitt Diverses
Zur Navigation springen Zur Suche springen

Stellenwert der Vererbung

Aus dem Artikel erst mal nach hier geholt, da etwas fragwürdig:

Deshalb wird Vererbung in der Objektorientierten Programmierung inzwischen sehr sparsam eingesetzt (vgl. Kreis Ellipse Dilemma in Liskovsches Substitutionsprinzip).

Kommentar:
  • "inzwischen sehr sparsam" kann ich so pauschal nicht nachvollziehen; ob und wie man Vererbung korrekt einsetzt, sollte von der konkreten Aufgabe abhängen, und weniger von Moden, die "inzwischen" kommen und gehen. Das ganze Smalltalk-System z.B. lebt regelrecht von Vererbung, die kann man da nicht "inzwischen sehr sparsam" einsetzen.
  • Das "Dilemma" ist keins; siehe im dortigen Artikel
  • Im Satz vor dieser Aufzählung steht, was hier aufgezählt wird, nämlich einige unstrittige Charakteristika der OOP. Die Interface-Bemerkung gehört zweifelsfrei nicht hierher und ist mir, wenn sie etwas bestimmtes aussagen will, so zu allgemein. -- Lukian 13:41, 8. Jul 2003 (CEST)

Viele Autoren von Fachbüchern gehen inzwischen sehr deutlich in Distanz zur Vererbung: 

* Nico Josurtis in "Erfolgreich mit Objektorientierung" (ISBN: 3486255657): "Vermeide Vererbung"

(die genaue Textstelle habe ich dezeit nicht zur Hand. Seite 77 in der zweiten Auflage) 

* http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

In dem Java-World Artikel kommt James Gosling (Java's inventor) zu dem Satz: Vermeide Vererbung wenn immer möglich!

Interfaces (Schnittstellen)

Zum Thema Interfaces: Seit es in Java Interfaces als Sprachelement gibt, werden Interfaces auch in anderen OO Sprachen (C#, Delphi ...) eingeführt. Neue Sprachen wie .NET und Java verzichten meines Erachtens nach ganz bewusst auf Mehrfachvererbung und bringen stattdessen Interfaces.

Ich gebe dir in sofern Recht, dass es bei OO um das Konzept der Polymorphie geht. Vererbung und Interfaces sind nur Umsetzungen dieses Konzepts. Aber dann sollten weder Interfaces noch Vererbung im Artikel als wesentliche Merkmale auftauchen.

Es ist eins der am meisten verbreiteten Missverständnisse, gegen die ich in meinen Schulungen kämpfe, dass OO = Vererbung ist. Diese Sicht war von 10 Jahren sicher richtig. Die Erfahrungen der letzten Jahre zeigen aber, dass Vererbung eher das Problem als die Lösung ist.

Dass sowohl Smalltalk als auch C++ Biblotheken reichlich Vererbung einsetzen ist sicherlich richtig. Das liegt aber zum großen Teil daran, dass die entsprechenden Systeme auch schon gut 10 Jahre alt sind. Moderne OO Software sollte Vererbung nur sehr sehr sparsam einsetzen (siehe Java World Artikel). Die Kombination aus Delegation (für die Wiederverwendung) und Interface für die Polymorphie ist auf jeden Fall die bessere Wahl.

Beispiel Ellipse

Das Kreis Ellipse Dilemma ist aus meiner Sicht ein gutes Bespiel, da schon dieses triviale Problem sich eben nicht mit einer Vererbung (ein Kreis ist ein Sonderfall einer Ellipse) lösen lässt. -- Guido 16:00h, 25. Jul 2003 (CEST)

Wer sagt, dass sich der Gipsverband nicht zur Behandlung einer Blinddarmentzündung eignet, hat natürlich recht. Wer sagt, dass sich Vererbung nicht für den Fall Ellipse/Kreis eignet, hat natürlich auch recht. Gleichzeitig spricht das weder gegen den Gipsverband noch gegen die Vererbung. Wer nach genügend häufigem Lesen der Clineschen Abhandlung http://users.utu.fi/~sisasa/oasis/cppfaq/proper-inheritance.html nicht früher oder später verinnerlicht (im englischen sagt man "to know by heart"), dass Vererbung für den Fall Kreis/Ellipse schlicht die falsche Behandlung ist, dem kann man nicht empfehlen, "Vererbung nur sehr sehr sparsam" einzusetzen, sondern dem muss man vom Einsatz der Vererbung ganz abraten, denn er könnte damit – weil unvollständig verstanden – einigen Schaden stiften. Wenn ein Arzt lauter solche Knochenbrüche auf dem Tisch hat, für die der Gipsverband die einzig angebrachte Behandlung ist, dann wäre eine Empfehlung an ihn, den Gipsverband "nur sehr sehr sparsam" einzusetzen, ziemlich unangebracht. Einem Blinddarmchirurgen gegenüber wäre die gleiche Bemerkung zwar nicht ganz so unangebracht, besonders klug klingt sie in dieser Situation aber auch nicht. Fazit: Es ist nicht besonders produktiv, über die Anwendungshäufigkeit eines Verfahrens zu reden, ohne die Eignung in der konkreten Situation zu berücksichtigen. Einem Programmierer, der weiß, was er tut, kann man die Entscheidung über die Mittel getrost selbst überlassen. Für einen Programmierer, der nicht weiß, was er tut, ist die Empfehlung, ein bestimmtes Mittel "sehr sehr sparsam" einzusetzen, genauso wertvoll, wie die Empfehlung an einen Arzt, der nicht weiß, was er tut, den Gipsverband nur sehr sehr sparsam einzusetzen -- Lukian 12:00, 9. Sep 2003 (CEST)

Interfaces sind nicht unbedingt erst eine Erfindung von Java. Und ohne den o.g. Artikel zu kennen, gehe ich davon aus, daß mit der Kritik an Vererbung gemeint ist, daß man nicht mit Gewalt alle Objekte voneinander ableiten sollte. Ganz meine Meinung. Ich für meinen Teil arbeite schon lange oft mit Aggregation (Einbettung von Objekten in andere Objekte), um den Aufwand von Mehrfachvererbung oder Interfaces zu vermeiden. Mh 22:56, 13. Apr 2004 (CEST)

Ok, zurück zum Ausgangspunkt. Es ging ja ursprünglich darum, ObjektorientiertesProgrammieren zu beschreiben. Und ich halte es für eine verbreitetes Missverständnis, dass Objektorientiertes Programmieren = Vererbung ist. Das wesentliche Konzept dabei ist die Polymorphie (späte Bindung u.s.w.) - Vererbung und Interfaces sind nur Wege, dieses Konzept zu realisieren. Daher sollte diese Trennung im Artikel entsprechend beücksichtigt werden.

Wenn mir diese Gleichung so isoliert und hinreichend aufdringlich vorgehalten worden wäre, wäre ich vielleicht ähnlich allergisch dagegen. Vererbung kenne ich als einen von sieben oder acht Begriffen der OOP, über die man Bescheid wissen sollte. Meine Allergie hält sich da in Grenzen. Vielleicht liegt die von dir offenbahr wahrgenommene Überbetonung von Vererbung gegenüber Polymorphie auch daran, dass Neulinge die Idee der Vererbung wegen ihrer Einfachheit etwas schneller verstehen als die Idee der Polymorphie und die Lehrer lieber das einfachere vor dem komplizierteren erzählen – ich weiß es nicht. Können wir uns vielleicht darauf verständigen, dass das wesentliche an der OOP wirklich erst mal das Objekt selbst ist? Wenn jemand wirklich versteht, dass ein Stück Software ein Individuum sein kann, ist ja schon viel gewonnen. -- Lukian 22:55, 15. Sep 2003 (CEST)

Um in deinem Bild zu bleiben:

Ich halte es gerade für Anfänger fatal, zu sagen: "Das wesentliche an der Chirurgie ist der Gips" - auch wenn man einige Erkrankungen am besten mit einem Gipsverband behandelt.

In der Objektorientierung ist eben vieles, was beim ersten Hinsehen wie ein Knochenbruch aussieht, letztendlich doch etwas anderes - und Gips würde fatale Spätfolgen mit sich bringen. -- Guido 12:00h, 16. Sep 2003 (CEST)

Schuld ist aber nicht der Gips, sondern der Arzt, der ihn falsch verwendet. Da kann man vielleicht eine neue Wissenschaft draus machen: Welches Halbwissen ist am wenigsten schädlich? Trotzdem ist Hochmut fehl am Platz. Jeder gerät mal in Situationen, in denen wirklich nicht genug Informationen für eine optimale Entscheidung vorliegen. Da hilft wahrscheinlich der gesunde Menschenverstand am ehesten. Und vielleicht wäre es deshalb nicht die schlechteste Empfehlung an den Programmierer: denk zuerst selbst, hör dann auf den Lehrer, und denk dann wieder selbst, denn am Ende musst du selbst durchschauen und verantworten, was du gemacht hast; auf keinen Fall sollte man blind irgendwelchen Empfehlungen folgen, wenn man es selber besser weiß. -- Lukian

Frage nach dem Fragile base class problem

Unter welchem Stichwort ist im Deutschen das Fragile base class problem bekannt? http://www.wikipedia.org/wiki/Fragile_base_class

So lange in der Liste http://www.jeckle.de/uml.de/ (oder anderen?) nichts dazu steht, müssen wir zuerst unseren gesunden Menschenverstand walten lassen. Hilfreich ist ein Vergleich mit der Geschichte des Bauwesens. Über Jahrhunderte sind immer wieder mal Gebäude eingestürzt, bis den Bauingenieuren aus Grübelei, Versuch und Irrtum klarer wurde, wie ein Fundament angelegt sein muss, damit es das gesamte Gebäude sicher trägt. Die Wissenschaft der Software-Technik ist dagegen erst wenige Jahrzehnte jung und hat mit Sicherheit noch eine Menge (auch bittere) Erfahrungen vor sich. Also: die Beschreibung beim oben zitierten Link zu "Fragile base class" bezieht sich darauf, dass ein ganzes Softwareprodukt unrettbar zusammenbrechen kann, wenn die Gesamtkonstruktion sich als zu große Belastung für das erweist, was in der Basisklasse als Fundament bereitgestellt wird. Dem Bauingenieur ist inzwischen klar, dass man auf ein Fundament einfach nicht unangemessen viel draufpacken darf, wenn man nicht den ganzen Bau gefährden will. Auch in der Softwaretechnik wird man scheitern, wenn man auf einer Basisklasse so viele Abstraktionsstufen aufbaut, dass die Gesamtkonstruktion unbeherrschbar wird. Wer diesen Fehler begeht, hat die Basisklasse überbeansprucht, deshalb hier der Vorschlag, diesen Fall vorläufig als "überbeanspruchte Basisklasse" zu bezeichnen, bis sich ein besserer Begriff findet. -- Lukian 12:03, 14. Sep 2003 (CEST)
Die Idee ist an sich gut; der Ausdruck Fragile base class problem hat aber eine genau umrissene Bedeutung, der man mit diesem Ausdruckk nicht gerecht wird. Es hat irgendetwas mit nötiger Recompilation zu tun; es verschieben sich irgendwelche Tabellen. Ich habe den englischen Artikel nicht ganz verstanden. Auch Java soll dem unterliegen .... --HHK 14:02, 15. Sep 2003 (CEST)
"Fragile Superklasse" beschreibt ein Problem, das auftritt, wenn die Superklasse geändert und rekompiliert wird, nachdem die Subklasse übersetzt ist. Beispiel: Die Superklasse kriegt in einer Methode einen neuen Parameter, damit ändert sich die Methodenspezifikation, und batsch, eine Subklasse, die noch die alte Spezifikation verwendet, hat ein schweres Problem. Das Problem ist per se erstmal unlösbar. Der UNterschied zwischen Java und C++ ist (glaube ich, in C++ kenne ich mich nicht (mehr) aus), dass unter C++ sich die Spezifikation einer Methode bzw. der Klasse als ganzes auch ändert, wenn sich irgendwas anderes an der Superklasse ändert. Es müssen also in der Regel alle Subklassen neu kompiliert werden, wenn sich an der Superklasse irgendwas tut. Java kann eine Änderung der Superklasse jedoch in der Regel ohne Rekompilierung der Subklassen verdauen, sofern sich nicht direkt an den verwendeten Methoden bzw. Membern nichts geändert hat. Uli 14:34, 15. Sep 2003 (CEST)
Ja, so weit ich herausgelesen habe, geht es um das fertige Kompilat eines Anwendungsprogramms, das jemand gern auch dann noch weiterverwenden möchte (wohlgemerkt als übersetzte Binärdatei), wenn in neueren Versionen der Laufzeitumgebung geänderte Versionen der ursprünglichen Basisklassen verwendet werden. Ich kann mir nicht helfen, mir drängt sich wirklich der Vergleich zum Bauwesen auf: Welcher Bauingenieur würde sich darüber wundern, dass ein in Stein fertig gebautes Gebäude nicht völlig nahtlos auf ein nachträglich geändertes Fundament passt? Die Bauingenieure haben im Laufe der Jahrhunderte eben gelernt, dass es vernünftiger ist, bei geändertem Fundament auch die nötigen Änderungen am Gebäude in Kauf zu nehmen. In der Softwaretechnik wird sich vielleicht auch mal die Einsicht durchsetzen, dass die Neukompilation des Anwendungsprogramms der vernünftigere Weg ist, anstatt die Basisklasse irgendwelchen vorher anders geplanten Ansprüchen auszusetzen und sich dann darüber zu wundern, dass das nicht reibungslos funktioniert. Im Grunde steckt dahinter wahrscheinlich einfach nur einen Versionskonflikt -- Lukian 22:11, 15. Sep 2003 (CEST)

Definition von Objektorientiert

aus Objektorientiert, von einem anonymen Benutzer: --Head 00:51, 29. Sep 2003 (CEST)

Objektorientiertheit ist ein Konzept der modernen Informatik, das im Gegensatz zur klassischen prozeduralen Programmierung, die strikt zwischen Daten und Prozeduren unterscheidet, beides als untrennbare Teile des Ganzen, des Objekt s behandelt. Die Zusammenführung geschieht folgendermaßen:

    • Daten - werden zu Attributen (Eigenschaften) des Objekts, z.B. "Name" als Eigenschaft des Objekts "Person",
    • Prozeduren - werden zu Methoden (Fähigkeiten, Dienste), die das Objekt ausführen kann, z.B. "speichern" des Objekts "Datei".

Objekte werden in sog. Klassen definiert. Weitere wichtige Merkmale der Objektorientiertheit sind die Instantiierung (z.B. Einrichten der Instanz "Bello" als ein spezielles Exemplar des Objekts "Hund") und die Vererbung ("Hund" übernimmt alle Eigenschaften des übergeordneten Objekts "Säugetier"). Objektorientiertheit wurde Mitte der 80er Jahre u.a. von den Informatikern Yourdon und de Marco eingeführt, um die Nachteile der bis dato favorisierten Strukturierten Analyse (Structured Analysis, SA) zu überwinden und Software leichter entwickelbar und wartbar zu machen. Die objektorientierte Analyse (OOA, object-oriented analysis) und -Design (OOD, object-oriented design) sind mittlerweile Standardverfahren der Softwareentwicklung.

Beispiele für objektorientierte Programmiersprachen sind Java, C++ und Ada.

Übertragene Diskussion aus dem nach Zusammenführung gelöschten Artikel Objekt (objektorientierte Programmierung)

Der Titel "Objekt (Programmiersprache)" ist etwas unpassend, denn es handelt sich bei "Objekt" nicht um eine Programmiersprache, sondern ein Konzept in der objektorientierten Programmierung.

Was haltet Ihr von "Objekt (objektorientierte Programmierung)"?

--zeno 11:36, 23. Apr 2003 (CEST)

Das wäre eindeutig viel besser --Lukian 17:34, 23. Apr 2003 (CEST)

Drei Sätze springen mir ins Auge:

  • Ein Objekt gehört immer einer Klasse an, und wird nach einer in der Klasse niedergelegten Bauvorschrift erzeugt (instanziiert).
  • In objektorientierten Sprachen sind alle Objekte Instanzen von Klassen.
  • Programmiersprachen, die keine Klassen, sondern nur Objekte haben, nennt man objektbasiert. Man erhält hier neue Objekte, indem man ein altes Objekt (den Prototyp) klont.

Müsste es im zweiten nicht heißen: "In klassenbasierten Sprachen ..."? Der erste Satz steht im leichten Widerspruch zu dem was folgt. Es sei denn man sagt, dass objektbasierte Sprachen keine objektorientierten Sprachen sind. Ich würde die Aussage _immer_ im ersten Satz irgendwie entschärfen.

Desweiteren:

  • C++ ist konventioneller: Klassen enthalten nur die Beschreibung von Objekten.

Inwiefern ist C++ konventioneller? Was ist an Smalltalk unkonventionell? Wie definieren wir hier konventionell?

--zeno 22:32, 23. Jun 2003 (CEST)

Da der zweite Satz fast das gleiche sagte wie der Anfang des dritten Absatzes, ist er vielleicht entbehrlich.
Die Begriffe "objektorientiert" und "objektbasiert" sind mit der hier verwendeten Bedeutung ziemlich direkt aus dem englischen "object oriented" und "object based" übernommen. Wer weiß genauer, mit welchen Inhalten "klassenbasiert" schon vorbelegt ist?
Das "immer" im ersten Satz war richtig, so lange wir uns streng an den Titel des Artikels halten, in dem ja ausdrücklich von "objektorientierter Programmierung" die Rede ist, und da gilt das "immer". Für objektbasierte Programmierung gilt es nicht - vielleicht schreibt jemand einen Artikel zu "objektbasiert"? -- Lukian 11:51, 24. Jun 2003 (CEST)

Der Unterschied koennte auch in diesem Artikel dargestellt werden. --zeno 13:47, 24. Jun 2003 (CEST)

Die Diskussion über das Objekt scheint eingeschlafen zu sein, daher frische ich sie wieder mal auf :) und ich beziehe mich auf die akt. Version des Artikels.

"In klassischen objektorientierten Sprachen sind alle Objekte Instanzen von Klassen."

Wieso klassischen? Ich würde sagen das ist wissenschaftlich definiertes Fakt in der Objektorientierung. Der folgenden Absatz suggeriert, Smalltalk gehört nicht zu den klassischen Sprachen (also wirds dort anders sein ...). Doch auch in Smalltalk sind alle Objekte Instanzen von Klassen (Metaklassen) oder etwa nicht?

Bei der Beschreibung von objektbasierten Sprachen (muss allerdings dazu sagen, dass ich von denen zum ersten mal höre und ka habe) versteh ich auch was nicht. Woher kommen die Objekte, wenns keine Klassen gibt?

"Es reicht prinzipiell aus, Prototypen, also bereits vorhandene Objekte zu klonen"

Was ist der Unterschied von einem solchen Prototyp zu einer Klasse?

Zs.gefasst finde ich den Artikel derzeit noch etwas verwirrend ... würde ihn gerne verbessern aber mir scheints da noch an Fachkenntnis zu fehlen. --brunft 23:52, 9. Mär 2004 (CET)

Ich hab doch mal einen Vorschlag zur Änderung gemacht. Und dabei ist mir auch ein Licht aufgegangen, was es mit diesem objektbasierten Sprachen auf sich hat und ich meine nun, doch Bescheid zu wissen.
"(...) zeichnet sich eine interessante Weiterentwicklung der klassischen, klassenbasierten OO ab"
IMO Humbug, denn objektorientiert programmieren ohne Klassen zu definieren ist vielleicht einfacher (weniger Schreibarbeit) aber nicht zugleich besser! Wenn ich richtig liege, ist es damit zu vergleichen, keine Datentypen anzugeben? Ich will jetzt nicht die unzähligen Nachteile (zB Fehlerquellen) im Detail aufzählen, die dadurch enstehen. Auf jeden Fall ist das keine Weiterentwicklung sondern simple Vereinfachung, die trotz Objektorientierung schnellere und einfachere Entwicklung von kleinen Prg. ermöglichen soll und spätestens bei der Entwicklung von komplexer Software an ihre Grenzen stößt.
Also der dritte Absatz gehört IMO unbedingt geändert. Mach ich gerne, wenns keine groben Einwände gibt ... --brunft 00:41, 10. Mär 2004 (CET)
Ich teile diese Ansicht. Das Einzige, was mir in der Richtung je über den Weg gelaufen ist, ist das Entwurfsmuster Protoyp. Ausserdem bezeichnet der Begriff objektbasierte Programmierung m. E. die Programmierung mit Objekten (und Klassen) jedoch ohne das Konzept der Vererbung (und manchmal auch ohne Schnittstellen). (Beispiele: Visual Basic, JavaScript). Siehe dazu auch die Abgrenzung im Artikel Objektorientierte Programmierung. Den Begriff "objektbasierte Objektorientierung" habe ich noch nie gehört. Was sagt denn Benutzer:Lukian dazu, von der Abschnitt ursprünglich stammt? -- Jpp 08:57, 10. Mär 2004 (CET)
Der Gegensatz ist nicht objektorientiert vs. objektbasiert, sondern objektbasiert vs. klassenbasiert. Beide Sorten von Sprachen (objektbasierte und klassenbasierte) sind objektorientierte Programmiersprachen. --zeno 09:43, 10. Mär 2004 (CET)

Hab den letzten Absatz jetzt ganz rausgenommen, und dann doch (stark) umformuliert versucht zu ersetzen. Nachteile sollten vielleicht noch ausformuliert werden --brunft 20:14, 10. Mär 2004 (CET)

Der Begriff Instanz ist ungern gesehen, da er schlicht durch einen Übersetzungsfehler des englischen „instance“ herrührt, was zu deutsch in diesem Kontext lediglich Exemplar bedeutet. Der Begriff Methode meint im deutschen eher das Entwicklungsverfahren, wie CRC-Karten, der Begriff Operation ist hier präziser. Anmerkung: Ich zöge die Formulierung „Programmierung nach dem Objekt-orientierten Paradigma“ eher vor, als von Objekt-orientierter Programmierung zu sprechen, da OOP nur eine Denkweise ist. Man sollte auf jeden Fall die Sprache Eiffel von Bertrand Meyer erwähnen. Und das Prinzip des Vertragsmodells wie „durch Zusicherungen von definierten Ergebnissen einer Operation und der Prüfung zu Laufzeit dieser Ergebnisse auf Erfüllung unter definierten Vorbedingungen, entsteht eine sich selbst kontrollierende Softwarekomponente.“ (oder so ähnlich)

--Just-Z

Auf der Hauptseite nicht mehr benutzte Formulierungen mit gewissem Wert

Abstraktion: Jedes Objekt im System verkörpert als abstraktes Modell einen "Arbeiter", der Aufträge erledigen kann, seinen Zustand berichten und ändern kann und mit den anderen Objekten im System kommunizieren kann, ohne offen zu legen, wie diese Fähigkeiten implementiert sind.

Das ist keine spezifische Eigenschaft der Objektorientierten Programmierung.
Egal wo ich geschaut habe, Abstraktion wird als wichtige Eigenschaft der OOP eingeführt (vgl. Google, Balzert, Gamma/Johnson, Doberkat/Dißman usw.). Abstraktion verbirgt die Implementierung und ermöglicht die Spezialisierung. Zum einen muss hier die Abstraktion von Implementierungen (prozedurale Impl.) und die von Eigenschaften/Datentypen betrachtet werden. Auf jeden Fall ist Abstraktion aber spezifisch. Warum sollte sie Deiner Meinung nach nicht spezif. sein? TG 13:57, 21. Feb 2004 (CET)
Mein Problem bei dieser Formulierung lag hauptsächlich darin, daß Abstraktion kein (exklusives) Kennzeichen der Objektorientierten Programmierung ist (im Gegensatz zu Polymorphie, Vererbung und zur verwendeten Definition von Kapselung), weil Abstraktion auch ohne OOP auftreten kann, z. B. in nicht-OO-Programmiersprachen, die "echte" Modularisierung unterstützen.
Ich habe diesen Konflikt nun dahingehend gelöst, daß ich das Wort "Kennzeichen" durch das weniger strenge "Eigenschaften" ersetzt und den Abstraktions-Text etwas entschärft habe und hoffe, daß Du damit einverstanden bist. Mh 22:38, 13. Apr 2004 (CEST)

Abstraktion ist sicherlich nicht erstmals mit OOP als Paradigma eingeführt, wird aber doch in der OOP in besonderer Weise abgebildet. In Klassenhierarchien sind aufeinander aufbauende Abstraktionstufen enthalten, das war bei Moduln und ADT nicht möglich. jh 21:30, 05. Jun 2004 (CET)

Vererbung stellt einen Verstoß gegen das Kapselungsprinzip dar, da für eine korrekte Vererbung Detailwissen über die Implementierung der Oberklasse benötigt wird.

Das stimmt nicht, denn das hängt von der konkreten Programmiersprache und weiteren Umständen ab.

Mh 15:01, 16. Feb 2004 (CET)

Der Hinweis ist nicht von der Hand zu weisen, ich würde sagen: Vererbung und Kapselung sind schon in gewisser Weise gegensätzliche Paradigmen. Um so mehr Vererbung eingesetzt wird, desto mehr Semantik ist eben außerhalb der Klassendefinition implementiert, nämlich in den Klassen, aus denen geerbt wird. Und genau hierdurch werden zu große Klassenhierarchien unbeherrschbar.

Es ist sogar ein großes Misverständnis, dass Kapselung spezilles Kennzeichen der OOP ist, dass sollte im Artikel besser entfernt oder zumindest relativiert werden. Ich habe den Eindruck, dass Kapselung (was ist das eigentlich, an diesen Begriff hat sich noch keiner herangetraut; vielleicht etwas wie die Konstruktion von Baugruppen in der Technik, Kennzeichen: in sich relativ abgeschlossen, mit überschauberer Wechselwirkung zur Umwelt) verwechselt wird mit der Instanziierung von Objekten. Das hat zwar nichts miteinander zu tun, letzteres ist aber durchaus ein Merkmal der OOP, dass in nicht-OO Programmiersprachen so nicht vorkommt und im Artikel nicht explizit erwähnt wird. jh 21:30, 05. Jun 2004 (CET)

"Einige Programmiersprachen handhaben das nicht ganz so streng und erlauben einen gewissen kontrollierten Direktzugang zu den Interna von Objekten"

Beispiel? Das führt ja schließlich die Kapselung ad absurdum (was ich auch reinschreiben würde ...) --brunft 22:08, 9. Mär 2004 (CET)

"Das ist ein Unterschied zu herkömmlichen prozeduralen Programmiersprachen, bei denen Daten und Prozeduren (...)"

In diesem Satz ist Unterschied mit dem Artikel Objektorientiert/prozedural verknüpft. Find ich ungünstig, denn als Leser von Wikipedia erwarte ich darunter die Beschreibung von "Unterschied", also klicken 99% auch nicht drauf ... ich ändere das mal, aber überhaupt ... sollte man den Artikel "Objektorientiert/prozedural" nicht in den Artikel einbinden? --brunft 23:58, 10. Mär 2004 (CET)

Kennzeichen der objektorientierten Programmierung

Ich würde hier noch die Objektidentität und Typisierung als wesentlich mit aufnehmen:

  • Objektidentität: ermöglicht eindeutige Identifizierung von Objekten
  • Typisierung: Objekte gehören zu einer Klasse, welche die gemeinsame Struktur und/oder des gemeinsamen Verhaltens ihrer Objekte beschreibt.

Wenn keine Einwände vorliegen, würde ich das in der nächsten Zeit noch hinzufügen. René Drießel 16:16, 30. Mär 2004 (CEST)

  • Die Typisierung in Klassen ergibt sich automatisch aus der Eigenschaft der Vererbung - falls die entsprechende Programmiersprache überhaupt zwischen Klassen und Objekten unterscheidet, was nicht der Fall sein muß.
  • Ich verstehe nicht ganz, was mit Objektidentität gemeint sein soll. Unter Umständen kann ich nicht unterscheiden, ob zwei Objekte mit demselben Wert auch das gleiche Objekt sind. Ich habe auch nicht unter allen Umständen einen Zeiger, einen Hashcode oder sonst ein eindeutiges Kennzeichen.
Mh 22:38, 13. Apr 2004 (CEST)
Bei der Objektidentität geht es um den Unterschied zwischem Gleichheit (d.h. gleiche Attribute) und Identität (gleiches Objekt im Speicher, bzw. gleiche OID in der Datenbank). Vgl. auch "==" und "equals" in JAVA. -- Guido 19:45, 27. Jun 2004
Typisierung ja, über Klassen nein. 1. Es gibt Objektorientierung ohne Klassen. 2. Gibt es aktuelle Ansätze und gute Gründe, Klassenhierarchie und Typhierarchie voneinander zu lösen. Ein gutes Beispiel sind Objekte aus zwei Klassen aus unterschiedlichen Klassenhierarchien, deren Methoden die gleiche Signatur haben. Warum sollen die denn nicht vom gleichen Typ sein? In vielen objektorientierten Programmiersprachen sind sie es zwar, aber halt nicht in allen. Literatur zum Thema: Martin Abadi und Luca Cadelli: A theory of objects. Die ersten fünf Kapitel behandeln unter anderem dieses Thema sehr gründlich.
Bei Objektidentität stimme ich völlig zu, das ist ein wesentliches Merkmal der Objektorientierung.--guwac 10:19, 19. Mär 2005 (CET)

Oktober 2004: Umformulierungen und Umbau

Ich habe ein paar Sachen umformuliert, sowie verschoben. Einen Teil vom Anfang weiter nach hinten gesetzt, wo er meiner Meinung nach besser passt. Bin aber für jede Meinung offen :-) -- TT 15:58, 10. Okt 2004 (CEST)

@Ulrich.fuchs: Die Stelle mit den "einzelnen Funktionsbereichen", die angeblich nicht mehr sequentiell durchlaufen werden, halte ich doch - vorsichtig ausgedrückt - für etwas gewagt...
...und "Benutzerführung" und "Bedienabläufe" sind Spezialthemen, die nicht in einführende Abschnitte zur OOP gehören, wo es ja um Grundsätzliches gehen soll.
Ich schlage vor, hier erst einmal ein paar Grundsatzüberlegungen anzustellen, bevor wir uns wieder an den konkreten Text machen. -- TT

Und ich schlage vor, dass Du Dir erstens mal ein gutes Buch zum Thema besorgst (bevor Du das Grundkonzept der Objektorientierung als "gewagt" bezeichnest), und Dir zweitens klar zu machen, dass sich nur aufgrund der Objektorientierung die grafischen Benutzeroberflächen programmierbar wurden. In den ersten Abschnitt gehört sehr wohl (grob) rein, warum man objektorientierte Programmierung macht. Und die zwei Hauptgründe habe ich angegeben, ich sehe keinen Grund, warum Du permanent meine Änderungen revertierst. Bitte unterlass das, ich empfinde das hier mittlerweile als recht unhöflich. - Uli 21:42, 15. Okt 2004 (CEST)
Ulrich, ich finde, der Benutzer, den du unhöflich nennst, ist sehr höflich zu Dir. Er versucht, die Arbeit mit Dir auf einen Nenner zu bringen. Du wirfst ihm vor, Deine Änderungen rückgängig zu machen, aber der Versionenhistorie entnehme ich, daß Du derjenige bist, der seine Änderungen kommentarlos revertet. Warum gehst Du nicht einfach auf seinen Vorschlag ein?
Ich fühle mich durch diese Diskussion dazu aufgefordert, meinen Senf hinzuzugeben ;-) Der gesamte Abschnitt bis Punkt 1 einschließlich Definition ist meiner Meinung nach sehr verbesserungsbedürftig:
  • OOP ist ein Ansatz, der sich auf den Typus einer Programmiersprache bezieht. So gesehen ist es eigentlich ein "Feature" einer Programmiersprache. Es ist somit kein Verfahren zur Strukturierung von Programmen sondern vielmehr das zugrundeliegende Modell einer modernen Programmiersprache.
  • Dass ein objektorientiert programmiertes Programm "anders arbeitet" als ein prozedural programmiertes, oder "nicht sequentiell", ist schlicht und ergreifend falsch. Jedes objektorientiert programmiertes Programm kann auch mit Hilfe einer rein prozeduralen Sprache programmiert werden. Auch konzeptuell ändert sich an der allgemeinen Sequentialität imperativer Programmiersprachen bei der OOP nichts.
  • Im darauffolgenden Abschnitt wird Programmierung und Benutzung eines Programms durcheinandergebracht. Der Benutzer eines Programms merkt von der OOP nichts. OOP ist ein Konzept, dass sich ausschließlich auf die Programmierung bezieht. Die Vorteile sind zunächst nur für den Programmierer da. Vorteile für den Benutzer ergeben sich höchstens indirekt. Ich kann nur nochmals betonen, dass alle in objektorientierter Sprache geschriebenen Programme auch rein prozedural realisierbar sind. --ni_ka_ro 20:53, 3. Apr 2005 (CEST)

Zur Programmierung von grafischen Benutzerschnittstellen: OOP ist nicht zwingend erforderlich; man kann auch mit Callback-Funktionen arbeiten. Das Win32-API ist meines Wissens nicht objektorientiert. Was man sicher sagen kann, ist, dass viele Leute denken, dass mit OOP da Programmieren von grafischen Benutzerschnittstellen einfacher ist.

Ein Wunsch: Ich hätte gerne eine gute Definition für OOP am Anfang des Artikels (möglicherweise selbstgebastelt, aber dann bitte auch noch klassische anerkannten SW-Ingenieuren) HannesH 12:41, 16. Okt 2004 (CEST)

Callbackfunktionen sind bereits ein konzept aus der Objektorientierung: Bestimmte Objekte (Beispielsweise ein Button) rufen ein anderes Objekt (einen Event Handler), wenn sich ihr Zustand aendert. Objektorientierte Programmierung kann auch ohne objektorientierte Programmiersprache funktionieren - es ist primaer eine Denkweise, kein Sprachspezifikum. Warum reicht Dir denn die Definition am Anfang noch nicht? - Uli
Zu Callbacks: Es gibt sie natürlich auch unter OOP. Historisch gab es sie aber schon vorher. Man kann damit umgehen ohne sich Gedanken über Klassen, Methoden und Vererbung etc. zu machen.
Zur Definition: Der erste Satz lautet: Objektorientierte Programmierung (OOP) bezeichnet die Anwendung der Objektorientierung auf die Strukturierung von Computerprogrammen, also die Programmierung.. Dieser Satz ist beinahe eine Tautologie. Eine analoger Satz: Brzäkzifierte Karambolagearbeiten bezeichnet die Anwendung der Brzäkzifierung auf die Strukturierung von PKW-Karambolagen, also PKW-Arbeiten. Klar? HannesH 10:11, 20. Okt 2004 (CEST)
Nicht ganz, weil "Objektorientierung" verlinkt ist. "Brzäkzifierte Karambolagearbeiten bezeichnet die Anwendung der Brzäkzifierung auf die Strukturierung von PKW-Karambolagen, also PKW-Arbeiten" Klar? ;-) "Objektorientierung" hat nen eigenen Artikel und ist dort definiert, die Definition der Objektorientierten Programmierung kann damit auf dieser Definition aufbauen. Ach so: Der Satz ist eine Tautologie, aber bei solchen Lemmata kommt man in der Regel nicht drum rum. - Uli
Im Prinzip einverstanden, wobei mir dann aber negativ auffällt, dass der Eintrag Objektorientierung extrem knapp ist. Das Konzept ist dort nicht wirklich erklärt. Ich würde mehr erwarten. Zudem ist mir als Leser des Artikels Objektorientierte Programmierung auch nicht klar, dass ich als erste Aktion in meinem Lesefluss auf Objektorientierung klicken soll. Sei's drum. Ich will hier nicht ein Drama machen. Ich will nur signalisieren, dass es mir bei der Definition nicht wohl ist. HannesH 22:18, 21. Okt 2004 (CEST)

Meiner Meinung nach ist es ein Widerspruch in sich, die Objektorientierung auf die Strukturierung von Programmen anzuwenden, denn letzteres wäre doch Strukturierte Programmierung, im Gesatz zur Objektorientierten Programmierung. 217.84.9.138 14:20, 9. Sep 2005 (CEST)

Programmierparadigma

Zitat Artikel:

"Prozedurale Programmierer schreiben Funktionen und übergeben ihnen dann Daten. Objektorientierte Programmierer erzeugen Objekte mit Daten und Methoden und lassen dann Nachrichten an diese Objekte schicken, die dafür sorgen, dass die so angesprochenen Methoden ausgeführt werden."

Ich finde, nach diesem Vergleich, dass OOP und "klassische" Programmierung immer noch sehr ähnlich, wenn nicht sogar identisch sind. Kann ein deutlicher Unterschied dargestellt werden, der den Vorteil und das Laufzeitverhalten zeigt? OOP lässt doch nach wie vor sequenziell die Daten durchrattern, oder?

Danke, --Abdull 13:39, 18. Feb 2005 (CET)

Ich habe es etwas umformuliert. Ich glaube, die Metapher mit den Nachrichten ist Missverständlich, weil sie ein anderes Laufzeitmodell suggeriert. Es geht aber in erster Linie um eine Strukturierung des Programms. --Flogger 19:24, 20. Feb 2005 (CET)

Objekt und Klasse

Der Artikel stellt im Abschnitt "Konzepte der objektorientierten Programmierung" das Konzept der Klasse als festen Bestandteil der objektorientierten Programmierung dar. Weiter unten steht aber, dass einige Programmiersprachen auf das Klassenkonzept gänzlich verzichten. Ich werde den Artikel dahingehend anpassen. --Flogger 17:30, 6. Mär 2005 (CET)

Gehören diese Begriffe wie viele andere hier auch nicht eine Stufe höher, in die Objektorientierung? Sie betreffen die objektorientierte Analyse genauso wie den objektorientierten Entwurf. Auch wird der Artikel durch die ganze Inline-Beschreibung tierisch aufgebläht. Ich wäre dafür, dass zentrale Begriffe wie Objekt und Klasse ausgegliedert werden und man sich in den ausgegliederten Artikeln um eine formal korrekte und allerlei verschiedene Aspekte berücksichtigende Darstellung bemüht, während hier eher in Kurzform alles zusammengefasst wird. Momentan öffnet man Parallelentwicklungen die Tür. Auch werden die Referenzen hier durch die Entwicklung des Artikels nicht erhalten. Viele Artikel verweisen z.B. auf OOP#Klasse, was gar nicht mehr existent ist. --guwac 10:33, 8. Mär 2005 (CET)
Ja, es betrifft im Grunde beides, sowohl die objektorientierte Analyse als auch den objektorientierten Entwurf. Aber beide Gebiete sind ja in der Kategorie "objektorientierte Programmierung" zusammengefasst, insofern passt auch der Artikelname.
In diesem Artikel einen Überblick in Kurzform geben, und einzelne Themen woanders vertiefen: Hört sich gut an, aber so war es ja vorher. Die Aufteilung, wie sie vorher war, hat sich jedenfalls nicht bewährt. Die bisherige Aufteilung war es nämlich, die eine Parallelentwicklung gefördert hat, zudem auf eine inkonsistente Art. Zur genauen Aufteilung müssen wir noch noch ein paar Überlegungen anstellen. Ich habe jetzt jedenfalls erst einmal alles zusammengeschoben, um eine homogene Darstellung zu schaffen, wobei nach Möglichkeit die einzelnen Abschnitte aufeinander aufbauen.
Objekt und Klasse würde ich zusammen lassen. Reißt man die beiden auseinander, dann wachsen die einzelnen Bestandteile automatisch so weiter, dass ein Großteil des jeweils anderen Teils wiederholt oder zur Erklärung vorausgesetzt wird. --Flogger 21:25, 10. Mär 2005 (CET)
Objektorientierte Programmierung steht meiner Meinung nach auf einer Stufe mit OOA und OOD und nicht darüber. Darüber wäre für mich Objektorientierung. Objekt und Klasse kann man auch ruhig trennen. Der Begriff des Objekts kommt ohne die Klasse aus, kann sie aber erwähnen, während der Begriff der Klasse auf dem des Objekts aufbaut. Sicherlich kann man sie aber auch in einem Artikel behandeln. Die Einordnung in die OO Programmierung finde ich daher so schwierig, da die Begriffe theoretisch fundiert dargestellt werden sollten, man bei Programmierung schnell mit praktischen Details und Umsetzungen bei der Sache ist. Ein Patentrezept habe ich auch nicht, zumal ich Deine Einwände zu Parallelentwicklungen nachvollziehen kann. --guwac 23:50, 10. Mär 2005 (CET)
Ich bin für die Trennung der theoretischen und praktischen Aspekte in verschiedene Artikel, frage mich aber, wie eine "theoretisch fundierte" Darstellung aussehen soll. OOP ist ja keine mathematische Disziplin. Auch ist es umstritten, was genau zur objektorientierten Programmierung gehört, und was nicht. Noch viel verwaschener ist der Begriff "Objektorientierung" - weshalb ich Bedenken hätte, ihn als Oberbegriff zu wählen.
Die zur Zeit im Artikel verwendete Beschreibung der Objekte, die über Methoden einander Nachrichten zukommen lassen, halte ich für erklärungsbedürftig. Wie man am obigen Kommentar von Abdull sehen kann, ist sie zumindest irreführend. In der Programmierpraxis spielt diese Metapher jedenfalls kaum eine Rolle. --Flogger 11:31, 12. Mär 2005 (CET)
OOP ist keine mathematische Disziplin, OO vielleicht schon. Die Begriffe Objekt, Klasse, Polymorphismus, Objektidentität, Objekttyp gibt es alle ohne Programmiersprachen, halt auch für die OOA und OOD und sind theoretisch fundiert. Programmiersprachen ändern gerne deren Bedeutung leicht, führen neue Begriffe ein oder belegen Begriffe neu. Das macht das alles halt schwierig. Wenn man z.B. oben diskutierte Typisierung nimmt: Wie lange dauert es denn, bis in diesem Artikel die unterschiedlichen Typkonzepte für Objekte in 1000 und 1 OOPS auftauchen? Darüber verschwindet dann die eigentliche Grundlage. Naja, und die für mich problematische Unterordnung von OOA und OOD hatte ich schonmal angesprochen. --guwac 10:27, 19. Mär 2005 (CET)
Ja, Programmiersprachen verschleifen die Begriffe. In C++ beispielsweise gibt es praktisch keinen wesentlichen Unterschied zwischen einer Klasse und einem zusammengesetzten Datentyp. Das wird schon durch die Wahl des Schlüsselwortes "class" diktiert. Dazu kommt, dass der Begriff "Objekt" aus C übernommen wurde, wo er lange vor dem Aufkommen von OO definiert wurde und dadurch heute zu vielen Missverständnissen beiträgt.
Aber auch das Wort "Objektorientierung" wird für verschiedene Zwecke eingesetzt. In der Boomzeit der OO war es ein Marketingschlagwort, und alles was man verkaufen wollte, schien irgendwie objektorientiert zu sein. "Objektorientierung" war geradezu ein Gütesiegel für Software.
Haben wir eigentlich z.Zt. Artikel zu einer formaleren ("mathematischen") Beschreibungen der Begriffe Objekt, Klasse, usw.? --Flogger 20:36, 19. Mär 2005 (CET)
Nein, diese Artikel gibt es nicht. Stattdessen wird in anderen Artikeln auf tote Anchors innerhalb dieses Artikels hier verwiesen, z.B. oben bereits erwähntes OOP#Klasse. --guwac 18:10, 22. Mär 2005 (CET)
Die toten Anchors und die formale Darstellung der OO-Begriffe sind zwei unterschiedliche Themen.
Wenn ich dich richtig verstehe, würdest du gerne bestimmte Begriffe (so wie z.B. "Klasse") wieder in Einzelartikeln abgehandelt haben. Lass uns aber bitte erst über die Gesamtaufteilung nachdenken. Im Moment sehe ich es jedenfalls als Vorteil an, alles in einem Artikel zu haben. Wenn wir uns über die Aufteilung im Klaren sind, können wir ja noch mal umbauen. --Flogger 12:13, 25. Mär 2005 (CET)
Also meinetwegen kann das alles in einen Artikel. Die formalen Definitionen von Objekt und Klasse sind ziemlich kompakt. Vielleicht ein Artikel Objekt_(Objektorientierung) und dazu ein Redirect von Klasse (Objektorientierung), das löst vielleicht auch das Anchor-Problem. Das grundsätzliche Konzepte wie Kapselung, Information Hiding, Abstraktion unter dem Begriff OOP statt unter OO gehalten werden, finde ich nachwievor problematisch. Ansonsten kann meinetwegen alles zusammenbleiben, müsste dann aber mal ergänzt, neu strukturiert und korrigiert werden. Einige Aussagen hier und in verlinkten Artikeln sind haarsträubend. Zu einzelnen Themen ausgelagerte Artikel wie Polymorphie bedürfen auch dringend einer Überarbeitung. Ich bevorzuge für mich zunächst die Arbeit an einzelnen Artikeln, bevor die dann durch einen Gesamtartikel miteinander verbunden werden. Vielleicht sollten wir das Ganze aber im WikiProjekt weiter diskutieren. --guwac 13:53, 30. Mär 2005 (CEST)
Weiterdiskutieren im WikiProjekt ist eine gute Idee. --Flogger 22:15, 2. Apr 2005 (CEST)

Vererbung

Was bringt mir Vererbung - außer unleserlicheren Code? --Abdull 01:46, 19. Mär 2005 (CET)

Wiederverwendung, ein immer wieder proklamiertes Problem der Software-Krise und Ziel in der Softwareentwicklung. Wenn Du mit Vererbung Unterklassenbildung im Allgemeinen meinst, zusätzlich alle Vor- und Nachteile von später Bindung und Typpolymorphismus. --guwac 10:10, 19. Mär 2005 (CET)
Bezüglich der Wiederverwendbarkeit bleibt die Vererbung hinter ihrem (ursprünglichen) Anspruch zurück. Der Wiederverwendbarkeit entgegen stehen die Abhängigkeiten zwischen Klassen, die man dadurch schafft. In jüngerer Zeit wird immer mehr vom Einsatz der Vererbung abgeraten.
Auf eine nützliche Anwendung von Vererbung wollte ich noch im Artikel eingehen. Dabei handelt es sich um eine verbesserte Modularisierbarkeit, vorwiegend unter Einsatz abstrakter Basisklassen, so dass sich Schnittstellen und deren Implementierungen elegant in unterschiedlichen Modulen unterbringen lassen. --Flogger 20:57, 19. Mär 2005 (CET)

Kapselung

Die im Text aufgeführten Zugriffsarten gehören meiner Meinung nach zum Begriff 'Information Hiding'. Bei der Kapselung sind Attribute eigentlich nur über Methoden zu ändern (interne Repräsentation verborgen, nur Verhalten sichtbar, wie es im Text auch richtig steht). Zugriffsmodifikatoren wie public, protected, private usw. verbergen nun einige dieser Methoden bzw. einige Programmiersprachen weichen den Zugriff auf Attribute auf, so dass mittels dieser Modifikatoren der Zugriff wieder beschränkt werden muss. Grundsätzlich lässt sich 'Information Hiding' auch über Subsumption zu Obertypen mit weniger Informationen realisieren. Die Modifikatoren sind eine Frage der Bequemlichkeit, Übersichtlichkeit und bieten darüber hinaus zusätzliche Möglichkeiten. In einigen OOPS erschweren Modifikatoren das Verhältnis Unterklassenbildung = Untertypbildung. So können in Eiffel z.B. Methoden verborgen werden, die vorher sichtbar werden. Wird dann ein Objekt im Kontext der Oberklasse verwendet, kann darauf natürlich die sichtbare Methode angewendet werden, die dann aber gar nicht mehr sichtbar ist. Zusätzliche Überprüfungen sind daher dann notwendig. --guwac 13:36, 19. Mär 2005 (CET)

In der englischen Wikipedia werden Information Hiding und Encapsulation gleichgesetzt. - Was nichts heißen muss. - Trotzdem wäre es interessant, eine Quellenangabe für diese Unterscheidung zu haben.
Einen Unterschied gibt es in jedem Fall zwischen den Begriffen Zugriff und Sichtbarkeit. Beispielsweise bleiben in C++ sichtbare Elemente trotz Einschränkung des Zugriffs durch Kennzeichnung als private immer noch sichtbar. --Flogger 22:15, 2. Apr 2005 (CEST)

Modul...

Beinhaltet "objektorientiert(/Objektorientierung)" von sich aus Module/Modularisierung (abgesehen von der durch die Objekte selbst gegebenen, natürlich)? --Alien4 18:35, 26. Apr 2005 (CEST)

Nein, nicht zwingend. ZB. in c++ kannst du viele klassen in einem modul (eine quelldatei oder eine bibliothek) packen. --Nikolaus 18:57, 26. Apr 2005 (CEST)
Kommt darauf an, wie due "Modul" definierst. Man kann natürlich eine Klasse auch als Modul betrachten, wegen der Datenkapselung. Aber für ein Modul- bzw. Komponentenkonzept sind noch andere Faktoren wichtig, z.B. das dynamische Binden. -- D. Dÿsentrieb ⇌ 19:51, 26. Apr 2005 (CEST)
Die definition von Modul ist tatsächlich die frage, im wp findet sich dazu auch keine definition unter Modul. Dynamisches binden ist aber sicher kein kriterium. Ein modul ist eine irgendwie zusammengefasste codesammlung, die schnittstellen zur anbindung an andere softwarekomponenten besitzt. OOP bedeutet jedenfalls auf keinen fall automatisch modularisierung (auch wenns schön wäre..). --Nikolaus 19:27, 28. Apr 2005 (CEST)
(Da frag ich mich doch, ob die "package" Zugriffsart (bis jetzt nicht mal in Klammern; auch wenn's auch unter UML dabei ist) zwingend in den Artikel gehört. Muss wohl so was sein wie Polymorphismus, der müsste wohl auch nicht zwingend sein.) --Alien4 23:49, 28. Apr 2005 (CEST)
Polymorphie ist eines der fundamentalkonzepte der oop, die frage ob es zwingend ist, scheint mir etwas unsinnig...--Nikolaus 14:28, 29. Apr 2005 (CEST)

Eigene Lemmas für grundlegende Begriffe

Ich finde es etwas unpraktisch, dass für grundlegende Konzepte der objektorienterten Programmierung (z.B. Klasse, Objekt, Methode) keine eigenen Lemmata mehr existieren. Wenn man einen Link darauf setzt, landet man in einem sehr großen Artikel und muss sich die gewünschte Information erst suchen. Stehe ich mit dieser Meinung alleine? Wurde das schonmal irgendwo diskutiert? --jpp 09:39, 25. Jul 2005 (CEST)

Lies dir mal diese Diskussionsseite gründlich durch. Steht alles drin. --Johannes2 20:04, 20. Aug 2005 (CEST)
Keine Ahnung, ob das schon diskutiert wurde, aber Du sprichst mir aus der Seele. Ich halte den Artikel so fuer wenig hilfreich. Wie waere es, die einzelnen Lemmatas herauszubrechen und durch includes in einen Ueberblicksartikel einzufuegen? -- sparti 15:21, 25. Jul 2005 (CEST)
Dagegen. Begründung auf dieser Diskussionsseite. (s.o.) --Johannes2 20:04, 20. Aug 2005 (CEST)
"Klasse (objektorientierte Programmierung)" gibt es als lemma. "Objekt" ist in der informatik ungefähr ähnlich allgemein, wie im sonstigen leben (du denkst dabei vermutlich an das, was man die "instanz einer klasse" nennen könnte, eine instanz eines integers ist aber auch ein objekt). "Methode" außerhalb dieses artikels zu erklären wäre eine große verdopplung von erklärungen. Bei diesen drei beispielen bin ich für die beibehaltung des ist-zustands. Gibt es noch andere beispiele für dein anliegen? --Nikolaus 18:21, 25. Jul 2005 (CEST)

Vererbung und Polymorphie

Polymorphie hat eigentlich nichts mit Vererbung zu tun. Bei C++ ist es so, dass Polymorphie nur innerhalb der Klassenhierachie möglich ist. Andere Programmiersprachen lassen Polymorphie auch zwischen nicht abgeleiteten Klassen zu: 

id anObject;

anObject = @"Dies ist ein String!";
NSLog( @"%@", [anObject description];

anObject = [NSNumber numberWithInt:1]; 
NSLog( @"%@", [anObject description];

Hier wird der gleiche Methodenbezeichner -description zur Laufzeit mit verschiedenen Methoden-Implementierungen benutzt, ohne dass diese Klassen miteinander verwandt sein müssen.

213.168.108.72 12:25, 29. Sep 2005 (CEST)

Mein Zusatz zum Thema Polymorphie wurde gelöscht. Ich habe in meinem Zusatz auch die Meinung vertreten, die im obigen Beitrag geäußert wird. In C++ und Java ist Polymorphie nur innerhalb der Klassenhierarchie möglich. Nur diese Art der Polyphormie wird im Abschnitt Polymorphie behandelt. Es wäre wichtig,die weiteren Möglichkeiten der Polymorphie bei anderen Programmiersprachen anzusprechen. -- Schmitther 18:39, 27. Sep 2006 (CEST)

Ich möchte noch ergänzen, dass Polymorphie auch (und insbesondere) außerhalb der objektorientierten Programmierung auftritt. Der Wikipedia-Artikel zur Polymorphie, auf den hier auch verwiesen wird, stellt die Spielarten der Polymorphie nebeneinander. Hiernach dürfte es eigentlich klar sein, dass man tunlichts zwischen universeller und Ad-hoc-Polymorphie unterscheiden sollte. In vorliegender Beschreibung der Polymorphie in der OOP wird eigentlich nur (etwas umständlich) das Overriding erklärt, und das ist allerhöchstens Ad-hoc-Polymorphie.

Kleine Anmerkung von Benutzer:212.204.27.188

"In einigen objektorientierten Programmiersprachen wie zum Beispiel JavaScript, NewtonScript und Self wird auf die Deklaration von Klassen gänzlich verzichtet."

Wird "Programmiersprache" synomym für die Form des Programmiertextes genutzt… oder müsste nicht doch korrekterweise zwischen Programmier- und Scriptsprache unterschieden werden? (yves dot vogl at gmail dot com)

programmiersprache sehe ich als überbegriff, der auch skriptsprachen beinhaltet, wobei letzteres auch ein sehr umstrittener begriff ist. -- ∂ 20:45, 8 November 2005 (CET)
Hab nochmal darüber nachgedacht. Oberbegriff ist ok – bin überzeugt. Was soll auch sonst als Oberbegriff dienen? Zur umstrittenen Verklausulierung "Skriptsprache" => sehe ich auch mit geteilter Meinung. Aber man gerät bei soetwas auch schnell in die Erbsenzählerei. Gruß, Yves
Skriptsprachen sind Programmiersprachen. Die Aussage, es würde auf die Deklaration von Klassen verzichtet, ist aber irreführend, oder zumindest unvollständig - es handelt sich um prototyp-basierte objektmodelle. -- D. Dÿsentrieb ⇌ 00:22, 10. Nov 2005 (CET)

Definition "Objekt" fehlt?

Ich habe ein Redirekt von Objekt (Informatik) hierher anlegen wollen, und zwar zu dem Abschnitt, der den Begriff "Objekt", wie er in der Informatik verwendet wird, definiert/erklärt. Klasse, Methode u.v.A.m. wird erklärt, aber "Objekt" nicht. Selbst der Link [[#Objekt]] zeigt ins Leere. :-( --RokerHRO 09:53, 9 November 2005 (CET)

Ich habe eine definition des begriffes Objekt (Informatik) geschrieben (kann noch erweitert werden). Ist nicht nur für OOP reserviert! --Nikolaus 15:01, 9 November 2005 (CET)
Die Reduzierung des Objektparadigmas auf die objektorientierte Programmierung ist IMHO nicht mehr hinreichend. Die Modellierung von Software bzw. Sachverhalten mittels Objekten hat zu einer weitaus umfangreicheren Methodik, die über reine Programmierung weit hinaus geht, geführt (OOA, OOD, Design Patterns usw.). Ich schlage vor, die grundlegenden Teile aus dem OOP-Artikel in den Objekt (Informatik)-Artikel zu verschieben und das Ganze im genannten Sinn abzurunden. Hat jemand dazu eine Meinung? Nopherox 20:13, 20. Jan 2006 (CET)
Für ein so umfassendes Thema wäre wohl eher das Lemma „Objektorientierung“ angebracht, statt „Objekt“, oder? --jpp ?! 00:47, 21. Jan 2006 (CET)
Ich hab das geändert. Im weiteren bitte acht geben auf konsistente Verwendung von Objektorientierung = Konzept und OOP = Programier-Vorgehen. --62.134.177.138 12:46, 4. Mär 2006 (CET)

Artikel in Bezug auf theoretische Aspekte äußerst mangelhaft

Habe nur die Abschnitte zur Vererbung gelesen, doch wird zumindest hier praktisch nicht auf die Semantik der Vererbung eingegangen, d.h. z.B. auf die Verpflichtungen/Constraints, die an Subklassen vererbt werden, etc. - da sollte noch viel mehr Wert auf fundierte Theorie gelegt werden (im Gegensatz zu: „Vererbung bedeutet, dass auch die Funktionen der Superklasse benutzt werden können“) 132.230.97.10 18:02, 21. Feb 2006 (CET)

Nachteile der Objektorientierten Programmierung

Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Dieser Punkt wurde am 20.Februar 2006 gelöscht, mit der Begründung „Nachteile entfernt (Umgewöhnungsschwierigkeiten und dynamische Speicherverwaltung haben nichts mit OO zu tun))“. Im Artikel werden vorwiegend die Vorteile der OOP genannt, während die Nachteile im gegenwärtigen Zustand verschwiegen werden. Insofern denke ich, dass ein solcher Abschnitt (auch meinetwegen auch als Anmerkung im bereits vorhanden Fließtext) Erwähnung finden darf. Ich habe diese beiden Aspekte aus dem Buch Informatik-Handbuch von Rechenberg und Pomberger aufgegriffen, was eigentlich eine sehr renomierte Lektüre im Bereich Informatik ist. Ich kann auch der Argumentation des Löschers nicht ganz folgen. Was spricht dagegen, OOP unter einem didaktischen Gesichtspunkt zu sehen? Ist es etwa so selbstverständlich, dass der Umstieg schwer fällt? Der Punkt mit dem höheren Speicherverbrauch ist natürlich relevant für die OOP. Wenn das kein Nachteil ist, dann kann man auch die Vorteile mit einer ähnlich schleierhaften Argumentation hinterfragen.

Also ich sehe nicht, wo OO zwingend höheren Speicherverbrauch impliziert. --RokerHRO 19:55, 14. Mär 2006 (CET)
Die OOP hat zum Ziel, eine höhere Wiederverwertbarkeit zu erzielen. (siehe Vererbung) Dieses Einbinden von weiteren Klassen und Objekten in Form von Modulen (Headerdateien und ähnliches), um davon wieder für den speziellen Gebrauch seine eigenen Klassen abzuleiten sorgt automatisch dafür, dass mehr Speicher für Dinge belegt wird, die in großen Teilen nicht genutzt werden. Daher nutzt man solche Sprachen auch nicht in Mikrocontrollern oder anderen Geräten, in denen Speicher und Rechenkapazität knapp ist. Bei dem PC kann man das mitlerweile fast immer vernachlässigen.
--Freak1.5 15:25, 19. Okt. 2006 (CEST)
Ich sehe auch keine relevante Zusatzinformation in dem Punkt, das etwas als schwer angesehen wird. -- 62.134.176.178 21:08, 15. Mär 2006 (CET)

nur so

zum aufheben: http://www.paulgraham.com/reesoo.html -- ∂ 23:56, 18. Apr 2006 (CEST)

Kritik

Letzter Kommentar: vor 18 Jahren4 Kommentare1 Person ist an der Diskussion beteiligt

Ich hatte folgenen Text entfernt, was aber von einer IP abgelehnt wurde:

Diesen Punkt beinhaltet für mich keine Kritik, außerdem ist es nur eine halbe Information. Was ist denn "im nicht einfachsten Fall"?
  • OOP steht mit der Objektorientierung dem Paradigma der relationalen Modellierung von relationalen Datenbanken gegenüber. Relationale Datenbanken bilden Assoziationen objektorientierter Modelle nach. Dies ist ein schlechter Stil da diese Informationen nun doppelt im Softwaresystem vorliegen. Dies wird verstärkt durch die grobe Granularität von Transaktionen auf Datenbanken gegenüber den feineren Methoden von Objekten.
Das ist schlicht Unsinn, sowie keine Kritik an der OOP sondern, wenn es denn richtig wäre, an den relationalen DB.

Ich werde den Text wieder entfernen, sollten in nächster Zeit keine fachlich begründeten Einsprüche kommen. --Revvar %&§ 19:47, 6. Mai 2006 (CEST)

das erste ist eine positive kritik, eine nichttriviale möglichkeit von oop. das zweite ist wieso unsinn? steht auch in der eng wp und bezieht sich klar auf oop. beides könnte sicher besser formuliert werden. --
ok, zum ersten Punkt: aha, das soll damit ausgedrückt werden. Passt aber nicht hierher sondern in OOA. Zum zweiten Punkt: Ich lese da nur eine Kritik (die ich für Unsinn halte) an den relationalen DB, aber nicht an der OOP. OOP steht nicht der relationalen Modellierung gegenüber. Das sind zwei paar Schuhe, und der Autor verwechselt anscheinenend OODBs mit OOP. Ab dem zweiten Satz klingt nach aus einem aus einem Skript abgeschrieben Stichpunkt zu den Vorteilen von OODBs. Wo bezieht es sich dort bitte klar auf OOP? - es geht um DB-Modellierung und SW-Technik. --Revvar %&§ 10:29, 9. Mai 2006 (CEST) (PS: eine Kommentar zur englische WP verkneife ich mir mal)
hm, ich lese keine oodb heraus, aber wäre aber ein lösungsvorschlag. es wird der (imo nichttriviale) punkt angesprochen, dass die daten (da üblicherweise rel. db) doppelt im sw-system / modellierung vorhanden sind und verschieden gehandelt werden, und das ist ganz klar schlecht und sollte erwähnt werden, da bei anwendung von oop dies beachtet/in kauf genommen werden muss. --
Die Kritik an OOP+RDB ist einfach zu pauschal und damit falsch, weil es durchaus gute Anwendungsfälle für OOP+RDB gibt, was wohl imho _einer_ der Gründe ist, warum sich OODBs und ORDBs viel langsamer verbreiten als Anfangs erwartet wurde. Es gibt wie üblich genug Pros und Kontras, aber wie auch immer, soetwas gehört in den Artikel ODB und hierher ein Verweis darauf. --Revvar %&§ 10:13, 10. Mai 2006 (CEST)
das es es trotzdem in der praxis gibt, macht doch die kritik nicht falsch. und sie ghört auch in oop, da das problem nur mit verbiegung wie o-r-m in oop gelöst werden kann. --
Verstehe ich dich richtig: Du möchtest hier schreiben, dass es eine positive Eigenschaft der OOP ist, dass es gut mit ODBs zusamenarbeiten kann? - wenn ja, dann sollte es auch so formuliert werden, und nicht als negative Kritik an den RDBs. --Revvar %&§ 13:05, 10. Mai 2006 (CEST)

Einleitungssatz unverständlich

Der LA war sicherlich überzogen, aber unglücklich finde ich den Artikelstart schon - das bei einem komplizierten Thema weite Teile des Artikels unverständlich sind, wenn man sich mit der Materie nicht auskennt ist sicher zu akzeptieren, aber das ich erst im fünften Satz erklärt bekomme, was denn nun dieses "Objektdingsda" (was ich womöglich in einer Zeitung gelesen haben könnte) ist, nachdem ich vorher mit (immerhin blau verlinktem) geschichtlichem Fachgebrabbel der Entwicklung verschreckt werde... hm. Ich kenne den Begriff zwar (weil mir häufig davon erzählt wird und ich bei dem ganzen "ja,ja" sagen doch auch was mitkriege), kann das aber nicht in eine verständliche Einleitung packen - wie wäre es, wenn der fünfte Satz ("Die Grundidee der objektorientierten Programmierung ist, Daten und Funktionen die auf diese Daten angewendet werden können möglichst eng in einem sogenannten Objekt zusammenzufassen und Daten und Funktionen welche nur innerhalb des Objekts benötigt werden nach außen zu kapseln.") noch etwas besser ausformuliert (was soll dieses "nach außen kapseln" bedeuten?) an zweite Stelle kommt, nach einem Satz Nummer 1 für Omi: OOP, auch OOP genannt, ist eine Art der Programmierung.? - und der ganze technische Kram mit Java und C und was nicht alles kommt dann danach, wo Omi und ich eh nicht mehr lesen, aber immerhin genug gelernt haben, um den Zeitungsbericht weiterlesen zu können...--feba 02:12, 12. Aug 2006 (CEST)

  • Was hältst Du davon:
Die objektorientierte Programmierung, kurz OOP, ist ein Ansatz zur Programmierung von Computern,
der darauf beruht, die zu verarbeitenden Daten gleichzeitig anhand ihrer Eigenschaften und der möglichen
Operationen zu klassifizieren. Im Gegensatz zu Ansätzen, welche Eigenschaften und Funktionen
nicht gemeinsam betrachten, werden durch dieses Paradigma die menschlichen Organisationsmethoden zum Verstehen
der Realen Welt besser unterstützt. 
OOP liegt demnach eine Aufteilung der zu beschreibenden Welt in Objekte mit ihren
Eigenschaften und Operationen zugrunde. Ergänzt wird dies durch das Konzept der Klasse,
bei dem Objekte aufgrund ähnlicher Eigenschaften zusammengefaßt werden. Hinzu kommt mit der Aggregation die
Unterscheidung zwischen dem Ganzen und seiner Teile. Bei den meisten objektorientierten Programmiersprachen
ist das Konzept der Vererbung zu finden, bei dem Eigenschaften zwischen Klassen hierarchisch ausgetauscht bzw.
ergänzt werden können. Seltener ist das Konzept der Mehrfachvererbung zu finden, welches das nichthierarchische
Austauschen von Eigenschaften erlaubt.
Das objektorientierte Programmierparadigma wird von den gängigen modernen Programmiersprachen wie Java, C++
und C# unterstützt. Im Kontrast dazu stehen prozedurale Programmiersprachen wie Pascal, Fortran
oder C. Die objektorientierte Programmierung wurde bereits Ende der sechziger Jahre als Lösungsansatz für die
Modularisierung und die Wiederverwendbarkeit von Programmen entwickelt. Die erste objektorientierte Programmiersprache
war Simula-67.
Meine Definition ist mit den Autoren Coad/Yourdon konform, ergänzt um bestehende Passagen. Gruß, ReqEngineer Au weia!!! 11:36, 12. Aug 2006 (CEST)
Super! - So ist das in meine Augen laienverständlich (und zwar wesentlich besser verständlich, als ich es bei diesem Thema für möglich gehalten hätte). Ich habe es zumindest verstanden, und das passiert mir bei Computerfachsprech eher selten. --feba 13:07, 12. Aug 2006 (CEST)
Danke. Deine Expertise als selbsternannter Laie ehrt mich ;-) Dann setz ich das mal rein. Gruß, ReqEngineer Au weia!!! 13:31, 12. Aug 2006 (CEST)
Habe die zwischenzeitlich erstellte Anpassung von Benutzer:Wilfried Elmenreich übersteuert, in der Hoffnung, Verständnis zu finden. Ich halte obenstehende Definition für noch omatauglicher. Gruß, ReqEngineer Au weia!!! 13:59, 12. Aug 2006 (CEST)

unverständlich

Ich verstehe den Satz nicht: ...ist ein Ansatz zur Programmierung von Computern, der darauf beruht, die zu verarbeitenden Daten gleichzeitig anhand ihrer Eigenschaften und der möglichen Operationen zu klassifizieren. Meine Fragen:

  • Kann man das vielleicht etwas verständlicher schreiben?
  • Welche zu verarbeitenden Daten sind denn gemeint?
  • Warum muss die Klassifizierung gleichzeitig stattfinden?

Auch mit Objektorientierte Programmiersprachen besitzen einen speziellen Datentyp – das Objekt. Damit ermöglichen sie die Objektorientierung. habe ich so meine Schwierigkeiten.

  • Wie genau wird denn die Objektorientierung mit diesem speziellen Datentyp ermöglicht?

--Fra Diavolo 18:58, 12. Aug 2006 (CEST)

Objektorientierte Programmierung zeichnet sich unter anderem dadurch aus, dass zusammengehörende Methode in Klassen zusammengefasst werden. Solche Klassen werden zur Laufzeit als Objekte instantiiert und dienen der Abbildung von "Objekten der Welt" wie Gegenstände, Lebewesen usw. mit Eigenschaften und "sinnvollen" Methoden. Beispielsweise sollte eine Klasse zur Abbildung eines Hundes Eigenschaften wie Rasse und Fellfarbe sowie die Methoden Laufen und Fressen enthalten. Man könnte die Rasse auch allein durch die davon vererbenden Klassen definieren (s.u.). In der objektorientierten Programmierung können Klassen Eigenschaften und Methoden von anderen Klassen erben. So erbt zum Beispiel ein Dackel von Hund. Vererbende Klassen können Eigenschaften und Methoden der Oberklasse überschreiben oder über neue Eigenschaften und Methoden erweitert werden. Alle Objekte haben gemeinsam, dass sie von einem "Super-Ober-Objekt" erben, welches einfach nur ein Objekt repräsentiert. Je nach Programmiersprache kann dieses Hauptobjekt Methoden bereitstellen, die die vererbenden Klassen sinnvoll überschreiben sollten, weil diese meistens nur als "stub" dienen. Zum Beispiel wäre in Java die Methode toString() in Object zu nennen. Andererseits kann man über diese Schnittstelle Methoden für die übergreifende Kommunikation bereitstellen. In Java sind hier zum Beispiel wait() und notify() in Object zu nennen. Ich hoffe, dass ich Deine Frage wenigstens indirekt beantworten konnte. -- Can Filip Sakrak 20:40, 13. Aug 2006 (CEST)

@Fra Diavolo: Wir sind hier keine Auskunft. Deine Fragen werden klar im Artikel beantwortet, wenn du den gesamten dazugehörigen Absatz liest. Ein komplette Oma-taugliche Einführung in die Welt der Programmiersprachen kannst du nicht in diesem Artikel erwarten, dafür gibt es Wikibooks. --Revvar (D RT) 09:31, 14. Aug 2006 (CEST)

Überschneidung mit Objektorientierung

Meines Erachtens behandeln beide Artikel exakt dasselbe Thema, daher bin ich für die Zusammenfassung in einen einzigen Artikel. Als Lemma schlage ich "Objektorientierte Programmierung" vor, "Objektorientierung" halte ich für unglücklich gewählt, da sich der Artikel ja doch nur auf die Programmierung bezieht (siehe erster Satz im Artikel Die Objektorientierung ist eine Ausprägung der strukturierten Programmierung) Wenn es keine Einsprüche gibt, so werde ich den Inhalt aus Objektorientierung in Objektorientierte Programmierung integrieren und eine Weiterleitung in Objektorientierung einbauen.

-- Wilfried Elmenreich 12:36, 14. Aug 2006 (CEST)

Wie in [1] (der reguläre Ort für diese Diskussion) steht, halte ich Objektorientierung schon für relevant, da es auch OO-Entwurf, OO-Analyse, OO-Datenbanken u.ä. gibt. Leider steht davon nichts im Artikel, da gebe ich Dir recht. Die meisten denken halt immer ans Hacken... MMN müßte man schon klären, ob nicht ein allgemeiner OO-Artikel neben der OOP stehen müßte. Die Welt besteht nicht aus Code allein! -- ReqEngineer Au weia!!! 13:12, 14. Aug 2006 (CEST)
Was hältst Du davon, dass wir uns das Ganze aufteilen? Überführ doch Du die zwei Artikel in OOP, dabei kannst Du ja Deine (von mir überklatschte) Einleitung reanimieren, und ich nehme meine derzeitige abstraktere Einleitung zu OOP und schneidere daraus einen eher philosophischeren Überblicksartikel. Gruß, ReqEngineer Au weia!!! 13:28, 14. Aug 2006 (CEST)
Geht in Ordnung, machen wir es so! -- Wilfried Elmenreich 13:57, 14. Aug 2006 (CEST)
OK! Ich habe mal den Inuse-Baustein wg. Beseitigung der Redundanzen reingestellt, damit es keine Bearbeitungskonflikte mit anderen wohlmeinenden Usern gibt. -- ReqEngineer Au weia!!! 17:36, 14. Aug 2006 (CEST)

Zweiter Schritt: damit die Beiträge der anderen Nutzer bei der Überführung nicht verloren gehen, hier die Contributions zum bestehenden Artikel Objektorientierung ... -- ReqEngineer Au weia!!! 10:07, 15. Aug 2006 (CEST)

Eigenschaft vs. Attribut

Letzter Kommentar: vor 18 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt

Könnte mir jemand den Unterschied zwischen Attributen und Eigenschaften (falls vorhanden) erklären und dann vielleicht auch im Artikel deutlicher herausbringen? Bisher habe ich folgende Interpretationsansätze der Definitionen des Artikels:

  • Attribute sind Namen für Eigenschaften, also Eigenschaft: rot - Attribut: Farbe
  • Eigenschaften gibt es für Klassen und Objekte, Attribute nur für Objekte

Die Richtigkeit des zweiten Ansatzes bezweifle ich, da er kaum einen Sinn ergibt. -- GrGr 12:20, 4. Sep 2006 (CEST)

Üblicherweise unterscheidet man nur zwischen Methoden und Eigenschaften, das Wort "Attribut" würde ich in diesem Zusammenhang also nur als Synonym für Eigenschaft nehmen. Eine Klasse kann die Eigenschaft "Farbe" haben, welche ihrerseits wieder (auf welche Weise auch immer) den Wert "rot" annehmen kann. Objekte sind nur instanzierte Klassen. Stell dir eine Klasse als einen Prototypen, ein Gerüst vor, dann ist das Objekt die Ausführung oder die Umsetzung. (Tschuldigung für meine plumpe Erklärung, siehe dafür aber die entsprechenden Artikel).
--Benji 23:06, 14. Sep 2006 (CEST)
Danke erst mal, dass jemand geantwortet hat. Wenn Attribut und Eigenschaft synonym sind, warum wird im Artikel ein künstlicher Unterschied erzeugt? Mir sieht es so aus, als ob Benji auf meine Frage geantwortet hätte, ohne in den Artikel zu schauen. (Was Klassen und Objekte sind, weiß ich.)
Im Artikel steht
Attribute
Objekte (Hosen, Jacken, Pullover, ...) besitzen verschiedene Eigenschaften (Farbe, Größe, Material, ...). Diese Eigenschaften eines Objekts heißen Attribute.
Eigenschaften
Die Daten in den Objekten und den Klassen bezeichnet man als Eigenschaften.
--GrGr 15:31, 29. Nov. 2006 (CET)

Ich würde Attribute und Eigenschaften synonym sehen, allerdings wird in dem Artikel so viel laienhaft zusammenfabuliert, dass es darauf auch nicht mehr ankommt.... -- ReqEngineer Au weia!!! 20:54, 29. Nov. 2006 (CET)

Ja, da hast du leider nicht ganz unrecht, auch wenn ich das nicht ganz so hart formulieren würde. Dennoch, irgendwo muss man ja anfangen. Ich habe den Abschnitt „Eigenschaften“ jetzt einfach mal ersatzlos gestrichen, um die potenzielle Verwirrung zu reduzieren. Es fehlt unter anderem noch die Abgrenzung zwischen (innerem) Zustand des Objekts und (von außen sichtbaren) Attributen. Habe aber leider gerade keine Referenz zur Hand, so dass ich momentan keine belegte Definition beisteuern kann. --jpp ?! 11:29, 30. Nov. 2006 (CET)
Wobei mir gerade auffällt, dass da gewisse Redundanzen zu Objektorientierung, Klasse (objektorientierte Programmierung) und Objekt (Programmierung) bestehen. Viel zu tun … und so wenig Zeit. --jpp ?! 11:39, 30. Nov. 2006 (CET)
Objektorientierung habe ich so aufgestellt, dass dort das abstrakte Prinzip beschrieben wird und hier bei OOP der Bezug zu Programmiersprachen hergestellt wird. Auch dies wird ja leider häufig verwechselt... -- ReqEngineer Au weia!!! 21:11, 30. Nov. 2006 (CET)

Kritik2

Letzter Kommentar: vor 18 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt

Erstmal der "Kritik" - Abschnitt wie ich ihn heute vorgefunden habe:

  • Das Konzept der objektorientierten Programmierung kann im allgemeinen dabei helfen, Programmcode zu modularisieren. Modularisierte Quelltexte sind in vielen Fällen leichter zu warten und können bedarfsgerecht in mehreren Projekten verwendet werden (Wiederverwendbarkeit), ohne den Verwaltungsaufwand zu erhöhen.
  • OOP steht mit der Objektorientierung dem Paradigma der relationalen Modellierung von relationalen Datenbanken gegenüber. Relationale Datenbanken und Assoziationen objektorientierter Modelle bilden etwa das gleiche ab. In modernen Systemen sind wegen der hohen Performanz die Informationen aus technischer Sicht in relationalen Datenbanken abgelegt, während sie sich aus der Sicht des Anwenders wie ein Objekt verhalten. Die hohe Performanz von Transaktionen auf Datenbanken steht dabei den intuitiv zugänglicheren Methoden von Objekten gegenüber.

nun zu meinen Anmerkungen:

  1. Wo ist denn die Kritik? In meinem Verständnis müste man unter dieser Überschrift doch Probleme oder Grenzen aufzeigen?
  2. OOP steht mit der Objektorientierung dem Paradigma der relationalen Modellierung von relationalen Datenbanken gegenüber. Relationale Datenbanken und Assoziationen objektorientierter Modelle bilden etwa das gleiche ab. Ist das so? Wozu braucht man denn dann noch objektrelationale Datenbanken und objektorientierte Datenbanken? Ist es nicht eher so, dass die relationale Datenbank nur einen Teil eines OO Modelles abbilden kann? Wie bringt man denn Vererbung und Polymorphie in einer relationalen DB unter?--84.73.34.113 14:36, 30. Nov. 2006 (CET)

Der Abschnitt Kritik kann getrost als Nonsens, Humbug oder auch Quatsch bezeichnet werden. Ersatzlos streichen! Hier werden Äpfel mit Birnen verglichen und eine Kritik ist das schon garnicht. Diese lustlose Kombination von Halbwissen und Gestammel ist ja peinlich. Leider kann ich es derzeit nicht freundlicher ausdrücken. -- ReqEngineer Au weia!!! 21:19, 30. Nov. 2006 (CET)

Um es noch ein wenig zu erläutern: was hat OOP mit RDB zu tun? Nix! Das eine ist ein Programmierparadigma, das andere eine Klasse Datenbanken. Die wesentlichen Merkmale eines Programmierparadigmas mit Implementierungsaspekten in Datenbanken in Beziehung zu bringen ist leider nicht ganz seriös. Außerdem gibt es zum Thema OO-Persistenz das Lemma Objektorientierte Datenbanken. -- ReqEngineer Au weia!!! 21:37, 30. Nov. 2006 (CET)
Na dann bin ich doch einfach mal mutig und lösche den Nonsens, Humbug und Quatsch. Wir werden ja sehen wer dann alles aufschreit ;-) --84.73.211.229 13:30, 2. Dez. 2006 (CET)

Subtyping

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

Mich wundert es etwas, dass der Begriff des Subtypings nicht auftaucht. Ich halte diese für ein wesentliches Kriterium der OOP. Vielleicht liese sich dadurch die etwas unsaubere Darstellung der Polymorphie ersetzen.

--Gar kein name 10:59, 16. Feb. 2007 (CET)

Ich möchte hierzu ergänzend anmerken, dass ich die im Artikel gemachten Bemerkungen zur Polymorpie wenig hilfreich finde. Auch der von mir nachgelegte Satz zu "overriding" und "Ad-hoc-Polymorphie" gefällt mir nicht mehr besonders. Das Overriding ist doch noch etwas anderes, als das Überladen.

Ich möchte bitten, über folgende Punkte einmal nachzudenken:

1. Polymorphie und Subtyping sind Typkonzepte. Es geht also zunächst um die Frage, ob eine Ausdruck wohlgetypt ist (ob also die Typen der Teilausdrücke zusammen passen). Diese Frage wird bei statisch getypten Sprachen zur Compilezeit entschieden. Die Frage, welche Methode jeweils aufgerufen wird, ist eine sematische und wird zur Laufzeit entschieden.

2. Unter dem Begriff Polymorphie wird ein ganzes Konglomerat von Konzepten zusammengefasst. Insbesondere sollte man genau zwischen universeller und Ad-hoc-Polymorphie unterscheiden. Im Zusammenhang mit OOP findet diese Unterscheidung fast nie statt. Dann kann so etwas nicht genau werden.

Wie gesagt, ich würde den Abschnitt über Polymorphie gerne durch einen über Subtyping ersetzen und bitte um Kommentare hierzu.

Danke.

--Gar kein name 19:29, 24. Feb. 2007 (CET)

Um die Diskussion, die nicht so richtig interessant zu sein scheint, etwas zu befördern, möchte ich folgende Sichtweise hinzufügen:

Durch das Überschreiben einer Methode (overriding, late binding) entsteht zunächst mal kein neuer Typ. Überschreibt man mit einer Methode gleichen Typs, bleibt auch der Typ des Objektes verändert. Überschreibt man mit einer Methode eines anderen Typs, so entsteht genau dann ein Subtyp, wenn der Typ der überschreibenden Methode Subtyp des Typs der überschriebenen Methode ist.

Außerdem kann ein Subtyp dadurch entstehen, dass eine Methode hinzugefügt wird.

Je nach Programmiersprache können Subtypen unabhängig von Vererbung entstehen.

Öhmja, ich bitte nach wie vor Diskussionbeiträge, weil der jetzige Absatz über "Polymorphie" --- wenn ich recht darüber nachdenke --- so nicht stehen bleiben kann.

Nur um Missverständnissen vorzubeugen: Von mir aus kannst du den Inhalt gerne so ändern, wie du es für richtig hältst. Aber schreib bitte ganze Sätze. --jpp ?! 22:27, 4. Mär. 2007 (CET)

Sind Datentypen auch Objekte?

Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Zu dem Begriff Datentyp wird ja eine Wertemenge mit den zugehörenden Operationen zusammengefasst,...wie zb bei int,...sind das dann auch Objekte?? nur so ne kleine verständnis Frage und vielen Dank im Voraus!

Das kommt auf die Implementierung an. In Smalltalk (Programmiersprache) sind es z.B. Objekte, in Java (Programmiersprache) nicht. -- Semper 09:21, 12. Mär. 2007 (CET)
Begrifflichkeit klären für richtige Antwort: Weiter oben in dieser Diskussion im Abschnitt Eigene Lemmas für grundlegende Begriffe steht: "Objekt" ist in der informatik ungefähr ähnlich allgemein, wie im sonstigen leben. Das steht nun im Widerspruch zu der Bezeichnung Objektorientierte... und beispielsweise auch zu der Bezeichnung ObjectModelDiagram in der UML. Die begrifflich richtige Frage hier wäre: Ist ein Datentyp eine Klasse?. Dann kann man sich die Antwort aus der Kenntnis der Programmiersprache schon eher selbst geben. Es kommt auf die Programmiersprache und deren konkrete Implementierung an, siehe oben. Verallgemeinert könnte man aber schon sagen, auch in C++ kann man einen int-Datentyp als eine Art Klasse ansehen: Er beinhaltet Daten (die Abbildung eines Ganzzahlwertes) und ermöglicht damit bestimmte Operationen (Methoden). Nur wird er in C++ nicht mit class int definiert, sondern der Compiler kennt int direkt. --HartmutS

Einleitung

Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Mit kommt die Einleitung recht oberflächlich vor, denn es wird nicht wirklich gesagt was OO von nicht-OO unterscheidet. Vielleicht kann man etwas konkreter werden indem man eine Formulierung ähnlich der folgenden anfügt:

Kern der objektorientierten Programmierung ist die Einführungen eines aktuellen Objektes (als this, self, oder Current bezeichnet) als Teil des Zustandes während der Ausführung. Im Gegensatz zur nicht-objektorientierten Programmierung, in welcher ein Name (identifier) auf eine globale Variable oder eine feststehende Routine verweist, werden in der objektorientierten Programmierung Variablen und Prozeduren relativ zum aktuellen Objekt ausgewählt.
Wird eine Variable relativ zum aktuellen Objekt definiert, spricht man zur Laufzeit von einem Feld oder Attribut des Objektes. Dies bedeutet, dass zwei Zuweisungen zum Feld x := 3 auf zwei unterschiedliche Speicherplätze den Wert 3 schreiben, wenn zu Zeit der Ausführung unterschiedliche Objekte aktuelles Objekt waren.
Des weiteren können Aufrufe von Prozeduren relativ zum aktuellen Objekt deklariert werden. Eine Prozedur, welche relativ zu einem Objekt definiert ist, wird als Methode bezeichnet. Der Aufruf f(3) kann für zwei unterschiedliche aktuelle Objekt unterschiedlichen Code ausführen. Den Vorgang des Verbindens von Aufruf und Code zur Laufzeit wird als dynamisches Binden bezeichnet.

--Schoelle 16:34, 7. Aug. 2007 (CEST)

Ereignis

Letzter Kommentar: vor 16 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt

Warum fehlt dieser Begriff? -- Kölscher Pitter 10:00, 9. Okt. 2008 (CEST)

Ist Ereignis denn für objektorientierte Programme anders definiert als für „herkömmliche“ Programme? --j ?! 16:58, 9. Okt. 2008 (CEST)
Ja natürlich. Wenn Schalter von Null nach Eins dann Prozedurxy. Das ist klassisch. Schalter(von Null nach Eins).Prozedurxy. Das ist objektorientiert. Nach dem Ereignis läuft einzig nur diese Prozedur. Alle anderen Anwenderprogrammteile ruhen.-- Kölscher Pitter 17:50, 9. Okt. 2008 (CEST)
So ganz ist mir noch nicht klar, worauf du hinauswillst. Meinst du Zustandsübergänge, wie sie beispielsweise in UML-Zustandsdiagrammen definiert werden? Die beziehen sich ja auch nicht immer auf Objekte, obwohl Effekte natürlich oft als Methodenaufrufe interpretiert und implementiert werden. Und was hat das mit mit der Nebenläufigkeit zu tun? Die gibt’s ja schließlich auch in klassischen Programmen, wenn auch seltener. Verwechselst du eventuell Nachrichten mit Ereignissen? (Mir fällt gerade auf, dass der Begriff der Nachricht auch noch nicht definiert ist.) --j ?! 18:02, 9. Okt. 2008 (CEST)
siehe Ereignis (Programmierung). -- Kölscher Pitter 18:35, 9. Okt. 2008 (CEST)

Kritik3

Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Der Abschnitt "Kritik" könnte noch überarbeitet werden, besonders die beiden letzten Zitate (Stepanov, Dijkstra) sind - ich sags mal so - fragwürdig, besonders aus heutiger Sicht.

zu Stepanov: der Mann ist hauptverantwortlich für die STL, die sicherlich geholfen hat, C++ zu einer der erfolgreichsten objektorientierten Sprachen zu machen - hört sich irgendwie widersprüchlich an. Ausserdem was heisst "mathematisch-begrenzte Betrachtungsweise"? Dass man zum Programmieren logisches Denken braucht? Und der Vergleich mit KI - im Gegensatz zu dieser funktioniert OOP :-)

zu Dijkstra: gerade er müsste es besser wissen, aber OK, der Artikel ist von 1994, da steckte OOP ja eh noch in den Kinderschuhen. Nur spätestens dann, wenn hochkomplexe Softwareprojekte im Industriellen Umfeld zu managen sind, wird man "Schlangenöl" wie z.B. Software Engineering oder OOP zu schätzen wissen, die konsequente Nutzung dieser Strukturen kann schon das eine oder andere Desaster (siehe Programmierfehler) vermeiden helfen.

Mittlerweile ist OOP Standard, und statt des Abschnittes "Kritik" fände ich etwas in der Art "Vor- und Nachteile", bezogen auf jeweilige Einsatzzwecke, Soft- und Hardwareumgebungen nützlicher (man kann natürlich erwähnen, dass OOP nicht in jedem Fall sinnvoll ist, Microcontrollerprogrammierung etwa), aber allein aus NPOV-Sicht ist der Kritik-Abschnitt doch eher einseitig. --Ayanami rei 16:48, 23. Dez. 2008 (CET)

Welches waren die ersten objektorientierten Sprachen

1980 kam mit Smalltalk eine vollständige OOP-Sprache heraus, die ihrerseits auf der objektorientierten Sprache Simula beruhte. Der Artikel sollte etwas stärker fokussiert und stilistisch verbessert werden. Nützlich wäre auch den Bezug zu Abstrakter Datentyp und Modul, bzw. Komponente herzustellen. Wer wagt es? --HHK

Der beste Neustart wäre wohl erst mal die Übertragung des englischen Artikels - sobald ich dazu komme. Lukian

Dieser Abschnitt kann archiviert werden. Reinhard Kraasch 09:29, 12. Jan. 2009 (CET)

Vererbung

> Die Übernahme der Merkmale des vorhandenen Objektes bezeichnet man als Vererbung.

Vererbung bedeutet meist auch eine Subtypbeziehung. Der Satz suggeriert IHMO aber, dass Vererbung nur den "Import" von Features aus der beerbten Klasse bedeutet.

Was möcht' das heißen "meist", geht's auch genauer? Wie wäre es mit "Wenn keine binären Methoden auftreten, also beim Subtyping der kontravariante Teil der ARROW-Regel nicht benutzt werden muss, ensteht beim Vererben ein Subtyp."? Oder vielleicht ein Beispiel? "In JAVA entsteht durch Vererbung immer ein Subtyp." Wobei das natürlich auch nicht ganz stimmt wegen des Problems mit den Arrays. ----

Dieser Abschnitt kann archiviert werden. Reinhard Kraasch 09:29, 12. Jan. 2009 (CET)

Techniken-Abschnitt

Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Self sollte Nummer eins in der Liste der Prototyp basierte Sprachen sein (da es vor den beiden anderen Sprachen entwickelt wurde und das Konzept als eine der ersten Sprachen als Basis eines Objektsystemes verwendete).

Smalltalk ist ein besseres Beispiel für eine Sprache mit first-class Klassen als Objective-C, da es den Ansatz "alles ist Objekt" hat und damit diese Eigenschaft deutlicher ist und tiefer in der Sprache verankert ist (Objective-C hat ja nicht einmal Integers, die eine Klasse haben). Außerdem hat Smalltalk die sauberere Syntax und das bessere Sprach Design.

Zitat: "Klassen werden in der Regel in Form von Klassenbibliotheken zusammengefasst, die häufig thematisch organisiert sind. So können Anwender einer objektorientierten Programmiersprache Klassenbibliotheken erwerben, die den Zugriff auf Datenbanken ermöglichen."

Der Punkt der Klassenbibliothek ist nicht, dass man sie erwerben kann, denn

1. es gibt freie Datenbankbibliotheken

2. der Punkt der Bibliothek ist es sie zu verwenden nicht sie zu erwerben oder zu installieren

Außerdem passt das Wort "thematisch" nicht zu Organisationsstruktur. Ich denke, dass "nach funktionalen Gruppen organisiert" dies besser beschreibt. Des weiteren ist es nicht speziell für Klassenbibliotheken, dass die eine solche Organisationsstruktur haben, auch prozedurale Bibliotheken sind nach Funktionalität sortiert, es gibt auch prozedurale Bibliotheken, die den Zugriff auf eine Datenbank erlauben. Es sollten deutlicher die Unterschiede einer Klassenbibliothek zu einer prozeduralen Programmbibliothek ausgearbeitet werden, insebsondere sollte auf den Begriff Framework eingegangen werden.

Der Abschnitt verbindet Techniken aus ganz verschiedenen Abstraktionsebenen, dies verwirrt.

Insgesamt sollte der Abschnitt Grundlegenend umgearbeitet werden, es sollte klar zwischen Software Design (Design Patterns, UML, ...), Sprachdesign (Prototype-Sprachen, Sprachen mit First-Class Klassen, ...) und Code-Organisation (Klassenbibliotheken, Frameworks) unterschieden werden.

--Sebastian42 21:12, 30. Okt. 2009 (CET)

Methoden und Modifier

Letzter Kommentar: vor 15 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Die Modifier verhindern den Aufruf einer z.B. privaten (private) Methode nicht. Da es immer Möglichkeiten gibt diesen "Schutz" zu umgehen. Bei C/C++ reichen hier Pointer auf die entsprechenden Funktionen, bei Java ist dies per Reflection-API möglich. Diese Modifier haben hier allein die Funktion Variablen und Methoden, die nicht zu einer öffentlichen API gehören, zu verbergen, bzw. es ist Aufgabe des Compilers dem Programmierer vor dem Aufruf/Änderung von geschützten Bereichen zu warnen und gegebenenfalls (je nach Einstellung) nicht zu kompilieren.

Es ist also im Grunde nichts weiter als eine zusätzliche Information an den Programmierer der fremden Code (von einem Mitarbeiter geschrieben oder fremden Bibliothek) verwenden will. Hierbei soll er davon abgehalten werden Funktionen/Variablen der nicht öffentlichen API zu benutzen, da dies Nebeneffekte für den Fremdcode haben könnte, die vom Schreiber der API nicht beabsichtigt waren und vom Verwender aufgrund fehlenden Quellcodes nicht eingeschätzt werden können. "Man hätte in der Dokumentation darauf hinweisen können, dass solche API-Bestandteile nicht genutzt werden dürfen, aber so warnt auch der Compiler davor." Siehe auch [2] und [3] -- 10:30, 15. Okt. 2009 (CEST)

Der Mechanismus dient dem Verbergen von Information. Das Umgehen dieser Verbergung bricht die Kapselung auf und widerspricht der Idee der OOP. Es werden nicht nur Teile einer API verborgen (dann hätte man einfach ein Modul), es werden auch innerhalb eines Programmteils Informationen verborgen. Dies ermöglicht den objektorientierten Stil. Selbst wenn es keinen expliziten Schutzmechanismus gibt (z.B. in Python) sollte objektorientierter Code nicht auf die Daten anderer Objekte zugreifen (Konsitenz, Entkopplung von Objekten, Wiederverwendbarkeit, Verständlichkeit)!

Ausnahmen von dieser Regl (in C++ friends) werden explizit Deklariert und nicht ohne Grund verwendet. Datenfelder sollten nicht öffentlich sein! In C++ einen Pointer auf eine Methode zu erhalten, ohne dass die Klasse das Anbietet (ohne von der Implementierung abhängig zu sein). Verbietet .NET Refelction auf private Member? Dann könnte man das anführen.

Eine guter OOP-Sprachen-Compiler mit explizitem Verbergungsmechanismus warnt nicht bei Verstößen gegen diesen sondern gibt einen Fehler aus. --Sebastian42 16:50, 1. Nov. 2009 (CET)

Merkwürdiger Gegensatz?

Letzter Kommentar: vor 14 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt

Ich hab keine Ahnung von Programmierung, aber mir ist aufgefallen, dass im ersten Absatz ein sehr merkwürdiger Gegensatz aufgebaut wird:

Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. (...) Im Gegensatz dazu beschreibt das in der objektorientierten Programmierung vorherrschende Paradigma eine strikte Trennung von Funktionen (Quelltext) und Daten (...)

- Steht hier die objektorientierte Programmierung im Gegensatz zur objektorientierten Programmierung???-- 212.144.82.28 14:21, 8. Feb. 2010 (CET)

Naja. Die Objektorietierung wird mit der Objektorientierung erklärt/definiert. Jetzt wird Bezug genommen auf "gewöhnliche" Programmiersprachen, wo Daten (Konstanten oder Variablen) und Funktionen streng von einander getrennt sind. Das ist bei der Objektorientierung das Gegenteil.-- Kölscher Pitter 15:26, 8. Feb. 2010 (CET)
Aber genau dieser Bezug ist ja unklar. Deshalb ja auch mein Einwand. Ich nehme mal an, mit der folgenden Passage sollen die "gewöhnlichen" Programmiersprachen angedeutet werden:
so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können
Und dazu befindet sich die OOP nun im Gegensatz, richtig?
Nur leider sprachlich missverständlich.
Ein anderes - willkürliches - Beispiel, nur zur Veranschaulichung:
120Hz-Monitore haben besondere Wiedergabeeigenschaften, so dass auch im 3D-Betrieb kein Rückeln auftritt. Im Gegensatz dazu haben 120Hz-Monitore eine doppelte Bildrate.
Auch ist der Bezug des Gegensatzes unklar.
Ich schlage folgende Formulierung vor:
Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, welche 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. Um dies zu verhindern, beschreibt das in der objektorientierten Programmierung vorherrschende Paradigma eine strikte Trennung von Funktionen (Quelltext) und Daten, dafür aber eine schwächere Strukturierung der Daten selbst.
oder:
Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, welche 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. Im Gegensatz zur zur nichtobjektorientierten Programmierung (in der eine solche Manipulation möglich ist) fordert die OOP eine strikte Trennung von Funktionen (Quelltext) und Daten, dafür aber eine schwächere Strukturierung der Daten selbst. -- 134.245.5.103 13:53, 10. Feb. 2010 (CET)
Der Satz sollte einfach wegfallen, er ist nicht nur missverständlich, sondern auch falsch.
Die gutgemeinten Versuche, ihn zu "reparieren", bringen dem Leser keine neue bzw. richtigere Erkenntnis.
Die OOP fordert keine strikte Trennung von Funktionen und Daten, sondern, wie im Satz vorher richtig beschrieben,
deren Bündelung in einem Objekt. Die nichtobjektorientierten Paradigmen würde ich hier gar nicht anführen,
die erlauben und verbieten alles mögliche, eine allgemeine Aussage, was die mit Daten und Funktionen machen,
ist daher auf jeden Fall falsch. Eine direkte Gegenüberstellung zur imperativen Programmierung
(was vielleicht die Intention des Satzes ist, wobei er dadurch auch nicht richtiger wird),
muss eigentlich nicht in den 1. Absatz, besonders, da das Wesentliche schon im Satz vorher gesagt wurde. --213.9.110.252 17:05, 14. Mär. 2010 (CET)

Objektorientiert nur ein Spezialfall von prozedural?

Letzter Kommentar: vor 14 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt

Als jemand, der bisher fast ausschließlich prozedural programmiert hat (z.B. C, Fortran, Pascal), kann ich dem Artikel nicht wirklich entnehmen, wo nun der fundamentale unterschied zur Objektorientierung besteht. Saubere prozedurale Programmierung strebt ebenso eine Datenkapselung an, so dass eine Routine über festgelegte Kanäle (z.B. die Überlagelisten der Variablen, was z.B. auch die Übergabe von zu verwendenden Routinen einschließen kann) mit der sie aufrufenden Programmeinheit kommuniziert, so dass man einzelne Routinen einfach austauschen kann, ohne im Programm mehr als den Namen (und im Makefile die Quelldatei) ändern muss. Bspw, wenn man einen Integrator für gewöhnliche Differentialgleichungen hat, und zwischen Algorithmen wie Cash-Karp, Dormand-Prince oder Bulirsch-Stoer allein durch Auswechseln der Routinen wechseln kann (auch modulares Programmieren genannt). All dies ist, mit etwas Disziplin, auch in C und sogar in FORTRAN 77 möglich, wie die berühmten Numerical Recipes und viele andere zeigen.

Mir scheint, dass Objektorientierung lediglich ein Spezialfall modularer prozeduraler Programmierung ist, der besonderen, mehr oder weniger vereinbarten Normen genügt. Es wäre schön, wenn jemand, der beide Seiten sehr gut kennt, die Unterschiede und Gemeinsamkeiten (ggf. in einem side-by-side-Vergleich) verdeutlichen kann.--SiriusB 12:50, 2. Mär. 2010 (CET)

Der wesentliche Unterschied zwischen OOP und jeder anderen Art zu programmieren, liegt in dem Instanziieren von Objekten und dem Vererbungsprinzip. Datenkapselung kennt man auch bei funktionalen Programmiersprachen, ist also nichts typisch prozedurales, aber beim prozeduralen und funktionalen Programmieren gibt es immer nur eine aktive Instanz jeder Funktion/Prozedur. Mit deiner Kritik hast du insofern recht als auch Klaus Wirth gerne darauf hinweist, dass viele Diskussionen über OOP nicht mehr bieten als eine Wiedererfindung der Datenkapselung, die man schon seit Anfang der Siebziger kennt. (Übrigens sind die OO-Konzepte genau so alt...) Gruss --Herbert Klaeren 19:42, 2. Mär. 2010 (CET)
Der Unterschied zwischen prozeduraler und OO Programmierung ist a) die Einführung einer Identität, dem s. g. aktuellen Objekt (this, self, Current, ...), welches meist implizit (oder teilweise explizit - siehe Python oder GObject) bei Funktionsaufrufen übergeben wird, und b) dass die genaue Auswahl von Funktionen (OO: Methoden) und Variablen (OO: Attributen) relativ zu diesem aktuellen Objekt erfolgt. Somit ist "x = 3" nicht mehr die Zuweisung zu einer global eindeutigen Speicherstelle, welche als "x" bezeichnet wird, sondern zu einem Attribut "x", welches ein Teil von "this" ist. Gleichfalls ist "f()" nicht ein Aufruf einer global eindeutigen Funktion "f", sondern das Aufrufziel kann je nach aktuellem Objekt dynamisch varrieren ("dynamisches Binden"). --Schoelle 23:15, 10. Mär. 2010 (CET)
Hmm, so etwas ähnliches gibt es aber auch in prozeduralen Programmiersprachen. In Fortran z.B. kann man innerhalb einer Routine auch eine andere Funktion (oder Routine) f mit Argument x aufrufen, die hier nicht global, sondern dynamisch referenziert wird. Ruft man die besagte Routine dann auf, übergibt man ihr dann den Namen einer konkreten Arbeitsfunktion (z.B. income_tax mit Argument income), die dann benutzt werden soll. In Numerical Recipes wird davon Gebrauch gemacht, etwa um einen allgemeinen Driver für ODE-Integration wahlweise mit einem Cash-Karp oder einem Bulirsch-Stoer-Algorithmus als eigentliches Integrationsverfahren aufzurufen. Auch Variablennamen werden innerhalb einer Routine dynamisch vergeben. Bisher sehe ich lediglich das Vererbungsprinzip als prinzipiellen Unterschied zum prozeduralen Programmieren an, gebe aber zu, mir darunter nicht wirklich etwas vorstellen zu können. Ich will nicht ausschließen, so etwas ähnliches auch in C- oder Fortran-Programmen realisieren zu können, auch wenn der Code dann sicherlich nicht mehr schön aussehen würde.--SiriusB 20:29, 25. Mär. 2010 (CET)
Sorry for jumpin' in – Fortran 90 hatte sich einige Tricks aus der OOP abgeschaut; aber schon in meinem Fortran66-Kurs (noch auf Lochkarten) arbeitete man mit dem beschriebenen Funktionsargument.
Ich denke, die Frage klärt sich am ehesten, wenn man die Migration von C auf C++ betrachtet. Stroustrup hatte das philosophische "Objekt als Abbild von einem Etwas aus der realen Welt" umgesetzt. Und dieses Dings, das "this", hatte dann Methoden, die man auf dieses Dingsda anwenden konnte. Z.B.: "DruckDich()" -- .print() oder das toString() von einem beliebigen Objekt, von dem man weiter garnix weiß. Und das Vererbungskonzept, durch sieben Generationen durchdekliniert, hatte auch massive Vorteile -- ich habe 15 Jahre prozedural arbeiten müssen und weiß OOP zu schätzen.
Ich halte mich für jemand, der "beide Seiten" sehr gut kennt, sehe aber keine Notwendigkeit für Vergleich und Wettbewerb.
  • Komplexe, langfristig robuste Anwendungen, in denen strukturierte Abbildungen aus der realen Problemwelt implementiert werden und wieder und wieder ausgebaut und erweitert werden, sind ohne OOP einfach nicht umsetzbar und zu pflegen.
  • Kleine, überschaubare Geschichtchen sind auch prozedural und mit einfachen Skriptsprachen machbar.
  • Weil "Numerical Recipes" angesprochen wurden: Gerade numerische Berechnungen bilden insofern keine Objekte aus der realen Welt ab, und sie sind deshalb nicht notwendig mit OOP zu implementieren; es gibt dazu irgendwelche Math-Klassen, innerhalb derer die Berechnung rein algorithmisch läuft und wo das Objekt nur den verwaltungstechnischen Überbau liefert. Ein Math.sin(x) nutzt also nicht zwingend die Vorteile von OOP aus, ist dem Wesen nach funktional und algorithmisch. Um den Disk-Titel umzudrehen: "prozedural ist 'nur' ein Spezialfall von objektorientiert" -- das geht immer, umgekehrt aber nicht.
HGZH --PerfektesChaos 21:39, 25. Mär. 2010 (CET)
Die Benutzung von Funktionspointern an sich ist nicht OO (Lisp lebt davon), sondern erst die Verwendung eines aktuellen Objektes und die (meist impliziete) Auswahl des Code relativ zu diesem Objekts. Die ermoeglicht, im Programmcode "subjektiv" zu denken ("mein Vater ist jemand anderes als dein Vater"), ein Denkansatz, welcher nah an der Intuition des Menschen liegt. Dies macht OO so erfolgreich. Vererbung ist ein nettes Nebenprodukt, aber fuer OO nicht wesentlich. --Schoelle 14:05, 1. Mai 2010 (CEST)

Kritiken

Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Unter dem Punkt "Kritik" steht als erstes :

"Luca Cardelli untersuchte für das DEC Systems Research Center die Effizienz von OOP-Ansätzen mit den Metriken Programmablaufgeschwindigkeit (economy of execution), Compilegeschwindigkeit (economy of compilation), Entwicklungseffizienz für große und kleine Teams (economy of small-scale development und economy of large-scale development) und die Eleganz des Sprachumfangs selbst (economy of language features).[1]"

Warum steht da denn nicht, zu welchem Ergebniss er kommt ? Oder soll mit dem Eintrag angedeutet werden, das OOP in all' den genannten Punkten gar nicht so gut abschneidet ? -- 80.171.43.158 12:35, 12. Apr. 2010 (CEST)

ein berechtigter Einwand. Und ausserdem bedeutet "economy" nicht "Eleganz". --Herbert Klaeren 09:57, 14. Apr. 2010 (CEST)

Begrifflichkeiten Methode - Paradigma ...

Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Im Text und auf der Übersichtsseite werden verschiedene, IMHO fast ausschließlich falsche Begrifflichkeiten benutzt. Während ich das Verständnis von OOP als ein "Paradigma" unterschreiben würde, ist die Bezeichnung als "Methode" oder gar "Programmierstil" absoluter Unsinn. Methode hat einen Erkenntnisgewinn zur Folge, ein Programmierstil beschreibt eine optische Formatierung eines Codes. Letzteres greift aber zu kurz, weil OOP mehr als seine Umsetzung ist - es ist ein komplett anderer Denkansatz. Ich würde vorschlagen, die Begriffe Paradigma und Konzept zu verwenden. --85.178.235.240 13:04, 30. Mai 2010 (CEST)

Elementfunktion

Schlimm genug, dass in der deutschsprachigen C++-Literatur (online) der Begriff Elementfunktion verwendet wird, ohne dass für Element eine klare Entsprechung in C++, geschweige denn in der OOP genannt würde. (Und wie denn auch?) Um so weniger dürfte dieser Fehlgriff in die allgemeine Beschreibung der OOP passen? Man gebe zum Beweis “Elementfunktion -C++” in eine Suchmaschine. Eine Literatursichtung, zeitlich wie thematisch breit gestreut, dürfte gängigeres und weniger idiosynkratisches zu Tage fördern. GeorgBauhaus 12:15, 20. Aug. 2010 (CEST)

OOP und Kontrollfluss

Letzter Kommentar: vor 14 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt

Die Behauptung im ersten Satz dieses neuen Abschnitts ist sehr zweifelhaft und durch nichts belegt. Als Fachmann für Programmiersprachen glaube ich nicht daran, dass das wirklich stimmt. Wiederverwendbarkeit von Code war wirklich nicht das primäre Ziel bei der Entwicklung von OOP. Der Rest des Abschnitts ist schwer verständlich und sollte in dieser Form nicht stehenbleiben, das verwirrt nur. Ich habe jetzt erst mal darauf verzichtet, den neuen Abschnitt ganz zu löschen, aber wenn der nicht entscheidend verbessert wird, muss ich das in Zukunft sicher mal tun. --Herbert Klaeren 11:14, 5. Jul. 2010 (CEST)

hm, hab mir das mal angeschaut, wie wär's den so: "Ein der häufig gehörten Verheissungen (Vorzüge?) des Objektorientierten Paradigmas ist bessere Wiederverwendbarkeit und Wartbarkeit ..." Zumindest ist das einer der heutzutage häufig gehörten Vorzüge, Quellen dazu: http://www.drdobbs.com/184415594 Reusability is one of the great promises of object-oriented technology. ... Oder im geschichtlichen Kontext: http://www.developer.com/java/other/article.php/3493761/The-Evolution-of-Object-Oriented-Languages.htm Simula. By the 1960s, programmers realized that programming systems needed to be broken up into small, manageable pieces. The introduction of Simula-67 brought with it the first true programming object, classes, and a form of inheritance; therefore, Simula is an important milestone in any discussion on O-O programming languages ... an der Sache mit dem Kontrollfluss könnte was dran sein, wie man das aber deutlicher zeigen kann... hmmm, sprachlich argumentieren wie in der 2. Quelle ? : Steve Yegge’s rather famous post, “Execution in the Kingdom of Nouns” has probably done more to frame and influence my thoughts about object-oriented programming (OOP) than anything else out there. <snip> I finally got a handle on why I feel that multithreaded work is significantly more difficult than it needs to be: the noun-oriented nature of the languages that I have written multithreaded code in.--141.52.232.84 18:25, 6. Jul. 2010 (CEST)
ja, das sieht gut aus, ich hab nur noch ein paar Kleinigkeiten getunt. --Herbert Klaeren 19:10, 8. Jul. 2010 (CEST)
Danke, finde ich auch, besser nun. --141.52.232.84 13:17, 9. Jul. 2010 (CEST)

Abschnitt Kritik

Letzter Kommentar: vor 13 Jahren11 Kommentare3 Personen sind an der Diskussion beteiligt

Im Abschnitt Kritik standen folgende Abschnitte:

  • Richard Stallman schrieb 1995: „Hinzufügen von OOP zu Emacs ist ganz klar keine Verbesserung; ich verwendete OOP bei der Arbeit am Fenstersystem der Lisp-Maschine und ich stimme dem häufig gehörten‚ ‚der überlegene Weg zu programmieren‘ nicht zu.“[1]
  • Alexander Stepanow meint, OOP beschreibt eine mathematisch-begrenzte Betrachtungsweise und nannte sie „fast einen genauso großen Schwindel wie die künstliche Intelligenz (KI)“.[2]
  • Edsger W. Dijkstra:
    „… die Gesellschaft lechzt nach Schlangenöl. Natürlich hat das Schlangenöl die eindrucksvollsten Namen – sonst würde man es nicht verkaufen können – wie ‚Strukturierte Analyse und Design‘, ‚Software Engineering‘, ‚Maturity Models‘, ‚Management Information Systems‘, ‚Integrated Project Support Environments‘ ‚Object Orientation‘ und ‚Business Process Re-engineering‘ (die letzten drei auch bekannt als IPSE, OO and BPR).“ – EWD 1175: The strengths of the academic enterprise[3]

Ersteres ist keine Kritik, sondern eine persönliche Vorliebe. Stallman verwendet sicher auch nicht Windows und findet dass Windows kein überlegenes Betriebssystem ist (dafür lässt sich sicher ein Zitat finden) - das wäre aber immer noch keine Kritik an Windows.

Auch Stepanow übt keine Kritik, sondern wirft mit Allgemeinaussagen um sich. Dass OO ein Schwindel ist (d.h. nicht real ist) glaubt er sicher selbst nicht.

Und auch Dijkstra übt mit keinem Wort Kritik an OO, sondern nur daran, dass es um OO einen Hype gegeben hätte.

Alle drei Aussagen sind (bis auf die von Stepanov, die ist undatiert) übrigens uralt (für IT Verhältnisse). Da sollte sich doch gerade bei einem so wichtigen Thema wie OO bessere Kritiken finden lassen. --Sebastian.Dietrich ✉ 12:55, 12. Dez. 2010 (CET)

Es liegt nicht an uns die Aussagen von Wegbereitern der Informatik kritisch zu interpretieren (Stepanow meinte sehr wohl was er sagte), Theoriefindung und OR lauern in der Nähe. Allein das sie eine Position zu diesem (besonders damals) vieldiskutierten Paradigma bezogen haben ist hier präsentierenswert genug. Und als Side-note zu Stallman, die Ernsthaftigkeit seiner Aussage wird durch die weiterhin überwiegende Verwendung von purem C durch sein GNU Projekt untermauert. Dijkstra Aussage, OO(P) als typischen Vertreter eines Schlangenölhype zu bezeichnen ist Kritik in seiner reinsten Form, unberechtigter Hype anstatt technischer Überlegenheit, siehe Schlangenöl: "Schlangenöl (aus dem Englischen snake oil) ist (hauptsächlich im Bereich von Software) die Bezeichnung für ein Produkt, das wenig oder keine echte Funktion hat, aber als Wundermittel zur Lösung vieler Probleme vermarktet wird." Stepanow schlägt in die selbe Kerbe, mehr braucht hierzu nicht mehr gesagt werden. Eine Kompromisslösung wäre für mich die Präsentation im historischen Kontext. Shaddim 15:33, 12. Dez. 2010 (CET)
Ok - wir haben also drei Personen (von mir aus auch "Wegbereiter der IT" was mMn etwas übertrieben ist), die Aussagen über OO (et.al.) tätigen. Darüber sind wir uns mal einig. Worüber wir uns nicht einig sind, ist ob diese Aussagen "Kritik" sind oder eben nicht (und es liegt natürlich an uns diese entweder als Kritik oder eben nicht zu interpretieren).
Bitte versuche zu erklären, was genau die Aussagen an OO kritisieren. Ich kann keine Kritik erkennen, sondern persönliche Vorlieben und Allgemeinaussagen. Keine sagt "OO hat diese Schwäche" oder "OO führt zu jenen Problemen". Aus Kritik: "Kritik bezeichnet .. eine prüfende Beurteilung nach begründeten Kriterien..".
Eine Enzyklopädie braucht substantielleres als diese Aussagen wenn an so weit verbreiteten Sache wie Kritik geübt wird (und Prozedurale Programmierung braucht genauso einen Kritik Abschnitt wie OO ;-) ) --Sebastian.Dietrich ✉ 17:24, 12. Dez. 2010 (CET)
Gut, wir haben Übereinstimmung darüber das dies drei relevante Personen der Informatikgeschichte sind und das sie eine Aussage über das OO-Paradigma treffen. Den Diskurs habe wir darüber ob der Abschnitt "Kritik" oder "Nachteile/Schwächen" heisst. Im zweiten Falle müsste eine allgemein akzeptierte und bekannte Tatsache/Aussage mit substantielle sekundären Quellen belegt werden, zu solchen können die drei "Wegbereiter" nicht dienen, sie vertreten tatsächlich nur sich selbst (haben aber Masse!). Im Fall der "Kritik"-Sektion wird nur aufgezeigt das es auch relevante (möglicherweise nicht mehrheitsgestützte) Stimmen gibt die einen Fakt oder hier eben Paradigma anders betrachten. Das Neutralitätsprinzip (NPOV) ist einer der der weiteren Stützen der Wikipedia und sollte hier zeigen das der Aufstieg des OOP durchaus umstritten und von Zweiflern umsäumt war/ist (die relevant sind). Zu der Frage ob diese Positionen überhaupt Kritik sind, Stallmans Aussage mag als negative Kritik gelten (sie die Taxonomie der Kritik), Stepanow und Dijkstra fallen schon in die destruktive Kategorie im deutschen auch als Verriss bezeichnet. Keine wissenschaftlich haltbare oder konstruktive Kritik (wie von dir gefordert), nichtdestotrotz Kritik von Schwergewichtlern der IT-Zunft die im Sinne des NPOV ebenfalls in einen Artikel gehören. Im übrigen gebe ich dir völlig Recht, auch die prozedurale Programmierung bräuchte mehr kritische Töne die ihre Ablösung als dominierendes Paradigma dem Leser verständlich machen könnte. Shaddim 18:34, 12. Dez. 2010 (CET)
Ob Schwergewicht oder nicht: Die Zitate lassen sich paraphrasieren mit "OOP ist ein Hype und ich halte es für schlechter als seinen Ruf". Damit kann man fast rechnen, der inhaltliche Wert der Aussage (in Bezug auf OOP) ist sehr gering. Man mag die Zitate bedeutsam finden, weil das bedeutsame Menschen gesagt haben – dann soll es eben in einen Abschnitt Rezeption oder noch besser Trivia ...
Aber Kritik ist einfach etwas anderes. Wer unter Kritik nur diese Zitate vorfindet, wird sich denken: Oh, da macht jemand den Hype nicht mit, aber Argumente gibt es keine; OOP scheint sich wohl zurecht durchzusetzen. Kurz: Je aufgeblähter die Kritik mit bedeutsamen aber inhaltsleeren Zitaten ist, desto klangloser gehen die wirklichen Kritikpunkte unter (sofern sie überhaupt genannt sind).
Und zu Dijkstra: Das Zitat ist aus einem Zusammenhang gerissen, in dem er sich eigentlich gegen das Marktgeschrei an Forschungseinrichtungen wendet, was er mit Beispielen darstellt, wo OO beiläufig genannt wird. Das ist nichtmal destruktive Kritik. Wenn ein Politiker sagt: "Das würde sich nicht mal Google trauen", dann ist das auch keine Kritik an Google. --Zahnradzacken 19:33, 12. Dez. 2010 (CET)
seltsam, war archiviert (der Bot nimmt an oben auf der Seite ist jung?) nun ist's wieder da die Diskussion, nun gut: zum Dijkstra Kommentar, hab' seinen Text nochmal rezipiert und kann diese Deutung nicht wiederfinden, im Gegenteil. Dijkstra spricht die soziale Verantwortung des akademischen Betriebs und kritisiert die Personen scharf die sich dem Wunsch der Gesellschaft nach verführerischem Schlangenöl beugen, wobei OO klar (wieso beiläufig?) als Beispiel genannt wird: "The external pressures to do the wrong thing are enormous, but yielding to them would be fatal for the academic enterprise, while resisting the pressure reinforces its strengths. The pressures are, in fact, so strong that I do not know a university where there is not some faculty or some department that has yielded, but there should be no mercy for snake oil pedlars on campus." ... sehr negativ dennen gegenüber die solcherlei verführerisches (aber für die Gesellschaft nicht gutes) Gedankengut und Konzepte (wie wohl OO) in die Gesellschaft zu entlassen. Solch eine starke Position sollte Teil der Seite sein, da es zur historischen Realität gehört das OO(P) mit Kritik und Kritikern kämpfte und kämpft. Rezeption als Abschnittsüberschrift wäre ebenfalls eine gute Lösung. Shaddim 17:40, 15. Dez. 2010 (CET)
ok, warte noch ein paar tage auf weitere beitraege dann nehme ich obigen vorschlag mit dem kapitel "rezeption" auf Shaddim 22:02, 22. Dez. 2010 (CET)
Da spreche ich mich auch dagegen aus. Auch unter Rezeption gehört gewichtigeres als Einzelaussagen (auch wenn diese von wichtigen Personen der IT kommen). Noch dazu wenn diese wie geschrieben breit über 7 Begriffe gehen und nichts spezifisch zu OO sagen. Ich bin mir sicher es lassen sich zu "Kritik" bessere Punkte finden (z.B. der Absatz davor über Performance & Produktivität) und zu "Rezeption", wie z.B. OO an Universitäten, am Arbeitsmarkt etc. aufgenommen wurde. --Sebastian.Dietrich ✉ 09:10, 23. Dez. 2010 (CET)
Na gut, Rezeption wuerde dann Sinn machen falls die gesamte Bandbreite der Rezeptionen (Markt, Andwender, Akademische und eben auch die kritischen Vordenker) dargestellt wuerden. Als Kritik sind diese Einzelmeinungen nicht spezifisch i.O., jedoch gewichtig, ich bleibe dabei. In welchen Kontext koenntest du dir eine Praesentation dieser drei Meinungen vorstellen? Ein breitbandiger Rezeptionsabschnitt erscheint mir jedoch eine der sinnvolleren Optionen. Shaddim 19:12, 30. Dez. 2010 (CET)
noch einer: Eric S. Raymonds "Art of Unix Programming" (19 September 2003): The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas.
auch überraschender schritt: Carnegie-Mellon University wirft OOP aus dem lehrplan. Professor Robert Harper März 2011: "This semester Dan Licata and I are co-teaching a new course on functional programming for first-year prospective CS majors... Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic."[4]Shaddim 17:32, 5. Dez. 2011 (CET)
Das ist aber eher ein Beispiel dafür dass es Uni Profs gibt, die keine Ahnung von ihrem Fach haben. Er schafft es leider in seinem Blog auch nicht zu erklären wie er zu dieser wundersamen Erkenntnis kommt. --Sebastian.Dietrich ✉ 19:33, 5. Dez. 2011 (CET)

Referenzen (zum Abschnitt):

  1. ↑ Richard Stallman: Mode inheritance, cloning, hooks & OOP. Google Groups Discussion, 16. Januar 1995, abgerufen am 21. Juni 2008.
  2. ↑ Alexander Stepanow: STLport: An Interview with A. Stepanov. Abgerufen am 21. April 2010.
  3. ↑ Edsger W. Dijkstra: EWD 1175: The strengths of the academic enterprise. 9. Februar 1994, abgerufen am 21. April 2010.
  4. ↑ Teaching FP to Freshmen

Weiterleitung von Membervariable

Letzter Kommentar: vor 13 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Die Seite Membervariable hat eine Weiterleitung auf diese Seite, ohne das der Begriff hier auch nur einmal erwähnt wird. --Wookie 13:41, 27. Jun. 2011 (CEST)

Stimmt, zusammen mit Member, was als Wort zwar genau einmal auftaucht, aber mit anderer Verwendung als man es erwarten würde. Ich halte eine Weiterleitung auf Klasse (Programmierung) für sinnvoller, wo dann die Begriffe gleich in der Einleitung erklärt werden könnte (wie bei en:Class (computer programming)). Hier könnte man sie auch nochmal im Abschnitt Klasse erwähnen. --Zahnradzacken 16:53, 27. Jun. 2011 (CEST)

Ereignisse?

Letzter Kommentar: vor 13 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

In diesem Artikel kommt das Wort Ereignis nicht vor. Fehlt da nicht was - wenigstens als Synonym (oder ähnlich) zu einem anderen OO-spezifischen Ausdruck? --VÖRBY 13:16, 26. Nov. 2011 (CET)

Zumindest erwähnen sollte man dass in der Praxis die OOP und Ereignisorientierte Programmierung gut kombinierbar sind.--Avron 21:08, 26. Nov. 2011 (CET)
Naja Events werden halt je Sprache unterschiedlich abgebildet, mal mit FunctionPointern, mal mit Observern --Sebastian.Dietrich ✉ 21:26, 26. Nov. 2011 (CET)

Anwendungsbereiche

Letzter Kommentar: vor 12 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Mich würde Anwendungsbereiche für OOP interessieren. Wo kommt sie mit welcher Intention zum Einsatz? --Das Robert .... gibs mir! 20:25, 7. Feb. 2012 (CET)

eine gute Frage... Das erinnert mich wieder an die Diskussion über einen breiteren Rezeptions- und Evaluationsabschnitt bzgl. der Konzepte, Versprechungen und Ergebnisse der OOP, gebildet aus der Rezeption im akademischen wie professionellen Bereich. Die Akzeptanz und das Verständnis der OOP ist durchaus Wandel unterworfen ... ach ja hier ist das Material noch im Diskussions-Archiv 2010 bei dem man beginnen könnte. gruss Shaddim (Diskussion) 17:29, 27. Mai 2012 (CEST)

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

Letzter Kommentar: vor 12 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt

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

Letzter Kommentar: vor 12 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

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

Letzter Kommentar: vor 11 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)

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)

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

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)
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)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:Objektorientierte_Programmierung/Archiv/1&oldid=237435651“