Diskussion:Objektorientierte Programmierung

.

So wahnsinning neu ist OOP auch nicht mehr. 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

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

Interface:Ein Interface bietet eine weiter Möglichkeit Polymorphie zu realisieren und vermeidet dabei die Probleme der Vererbung.

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.
* 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!

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.

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

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)

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.

Von der Hauptseite hierher verschoben:

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

Ebene 2 Überschrift

Link-Text--217.6.178.237 12:18, 19. Aug 2004 (CEST)--217.6.178.237 12:18, 19. Aug 2004 (CEST)

--217.6.178.237 12:18, 19. Aug 2004 (CEST)--217.6.178.237 12:18, 19. Aug 2004 (CEST)

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 durchgesetzt haben. 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)