Diskussion:Objektorientierte Programmierung

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis 1 Welches waren die ersten objektorientierten Sprachen 2 Stellenwert der Vererbung 2.1 Interfaces (Schnittstellen) 2.2 Beispiel Ellipse 3 Frage nach dem Fragile base class problem 4 Definition von Objektorientiert 5 Auf der Hauptseite nicht mehr benutzte Formulierungen mit gewissem Wert 6 Kennzeichen der objektorientierten Programmierung 7 Oktober 2004: Umformulierungen und Umbau 8 Programmierparadigma 9 Objekt und Klasse 10 Vererbung 11 Kapselung 12 Modul... 13 Eigene Lemmas für grundlegende Begriffe 14 Vererbung und Polymorphie 15 Kleine Anmerkung von Benutzer:212.204.27.188 16 Definition "Objekt" fehlt? 17 Vererbung 18 Artikel in Bezug auf theoretische Aspekte äußerst mangelhaft 19 Nachteile der Objektorientierten Programmierung 20 nur so 21 Kritik 22 Einleitungssatz unverständlich 23 unverständlich 24 Überschneidung mit Objektorientierung 25 Eigenschaft vs. Attribut 26 Kritik2 27 Subtyping 28 Sind datentypen auch Objekte?

[Bearbeiten] 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

[Bearbeiten] 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).

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

[Bearbeiten] 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.

[Bearbeiten] 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

---

[Bearbeiten] 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)

---

[Bearbeiten] 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:

1. • 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.

---

[Bearbeiten] 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)

---

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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.

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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. ----

[Bearbeiten] 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)

[Bearbeiten] Nachteile der Objektorientierten Programmierung

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)

[Bearbeiten] nur so

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

[Bearbeiten] Kritik

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

• Im einfachsten Fall dienen Objekte dazu, Dinge der realen Welt zu modellieren (Abstraktion).

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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] Ü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)

• 2006-08-14 15:35 (diff) ReqEngineer (Inuse-Baustein wg. beschlossener Beseitigung der Redundanzen)
• 2006-08-14 10:25 (diff) ReqEngineer (Redundanzbaustein)
• 2006-08-03 09:00 (diff) 62.157.214.195 (anon)
• 2006-08-03 08:56 (diff) 62.157.214.195 (anon) (/* Attribute */)
• 2006-08-03 08:55 (diff) 62.157.214.195 (anon) (/* Attribute */)
• 2006-08-03 08:54 (diff) 62.157.214.195 (anon)
• 2006-08-03 08:46 (diff) 62.157.214.195 (anon) (/* Klassen */)
• 2006-08-03 08:46 (diff) 62.157.214.195 (anon) (/* Klassen */)
• 2006-08-03 08:45 (diff) 62.157.214.195 (anon) (/* Klassen */)
• 2006-08-03 08:44 (diff) 62.157.214.195 (anon) (/* Klassen */)
• 2006-07-25 20:07 (diff) 213.3.72.92 (anon)
• 2006-07-21 07:58 (diff) 62.134.231.229 (anon) (/* Klassen */)
• 2006-07-21 07:56 (diff) 62.134.231.229 (anon) (/* Grundlegende Begriffe */)
• 2006-07-19 08:37 (diff) 193.27.50.74 (anon)
• 2006-07-17 22:22 (diff) 62.134.227.28 (anon)
• 2006-06-18 23:55 (diff) (minor) Kh80 (gelöschte Navigationsleiste)
• 2006-05-31 09:48 (diff) 132.199.33.104 (anon) (/* Polymorphie */)
• 2006-05-29 22:03 (diff) 62.206.114.179 (anon) (/* Klassen */)
• 2006-05-22 06:36 (diff) (minor) Ulz (rev vandalismus)
• 2006-05-22 06:35 (diff) 217.245.63.218 (anon) (/* Grundlegende Begriffe */)
• 2006-05-22 06:28 (diff) (minor) Seewolf (Änderungen von de:Benutzer:217.245.63.218 rückgängig gemacht und letzte Version von de:Benutzer:Seewolf wiederhergestellt)
• 2006-05-22 06:26 (diff) 217.245.63.218 (anon) (/* Grundlegende Begriffe */)
• 2006-05-22 06:25 (diff) (minor) Seewolf (Änderungen von de:Benutzer:217.245.63.218 rückgängig gemacht und letzte Version von de:Benutzer:Seewolf wiederhergestellt)
• 2006-05-22 06:24 (diff) 217.245.63.218 (anon) (/* Klassen */)
• 2006-05-22 06:24 (diff) (minor) Seewolf (Änderungen von de:Benutzer:217.245.63.218 rückgängig gemacht und letzte Version von de:Benutzer:Seewolf wiederhergestellt)
• 2006-05-22 06:22 (diff) 217.245.63.218 (anon) (/* Grundlegende Begriffe */)
• 2006-05-22 06:21 (diff) (minor) Seewolf (Änderungen von de:Benutzer:217.245.63.218 rückgängig gemacht und letzte Version von de:Benutzer:Seewolf wiederhergestellt)
• 2006-05-22 06:20 (diff) 217.245.63.218 (anon) (/* Grundlegende Begriffe */)
• 2006-05-22 06:20 (diff) (minor) Seewolf (Änderungen von de:Benutzer:217.245.63.218 rückgängig gemacht und letzte Version von de:Benutzer:84.166.91.220 wiederhergestellt)
• 2006-05-22 06:18 (diff) 217.245.63.218 (anon) (/* Grundlegende Begriffe */)
• 2006-05-22 06:16 (diff) 217.245.63.218 (anon) (/* Methoden */)
• 2006-05-03 09:08 (diff) 84.166.91.220 (anon) (/* Klassen */)
• 2006-04-28 08:07 (diff) Hhoffmann (/* Grundlegende Begriffe */)
• 2006-04-21 15:12 (diff) (minor) Peu (/* Grundlegende Begriffe */ link Klasse korr.)
• 2006-04-14 10:30 (diff) 62.134.233.151 (anon) (obj)
• 2006-04-10 20:21 (diff) 62.134.233.228 (anon) (+klasse)
• 2006-04-10 20:13 (diff) 62.134.233.228 (anon) (in Datenkapselung)
• 2006-04-08 11:03 (diff) 62.134.231.115 (anon)
• 2006-03-26 14:58 (diff) 87.78.179.169 (anon)
• 2006-03-12 16:26 (diff) 62.134.176.80 (anon) (einord)
• 2006-03-09 18:31 (diff) 62.134.176.36 (anon)
• 2006-03-09 18:03 (diff) 62.134.176.36 (anon) (link)
• 2006-03-05 19:25 (diff) 62.134.177.65 (anon) (weißer schimmel)
• 2006-03-04 12:43 (diff) 62.134.177.138 (anon)
• 2006-03-04 12:33 (diff) 62.134.177.138 (anon) (/* Weblinks */)
• 2006-03-04 12:22 (diff) 62.134.177.138 (anon)
• 2006-03-04 11:39 (diff) 62.134.177.138 (anon)
• 2006-03-04 11:37 (diff) 62.134.177.138 (anon) (/* Klassen */ in oop)
• 2006-03-04 11:32 (diff) 62.134.177.138 (anon) (steht dort)
• 2006-03-04 11:32 (diff) 62.134.177.138 (anon) (zu klein)
• 2006-03-04 11:06 (diff) 62.134.177.138 (anon) (is konzept)
• 2006-03-03 23:19 (diff) 62.134.233.180 (anon) (/* Vererbung */)
• 2006-03-03 23:16 (diff) 62.134.233.180 (anon)
• 2006-03-03 23:11 (diff) 62.134.233.180 (anon) (konzept vs. programmierung)
• 2005-11-14 12:40 (diff) Archiv (erfasst paradigma)
• 2005-09-26 07:26 (diff) (minor) Sparti (kat)
• 2005-07-21 08:59 (diff) Thomasv (revert)
• 2005-07-18 11:31 (diff) 149.201.206.156 (anon)
• 2005-04-13 19:35 (diff) (minor) Sparti (Kategorie)
• 2005-04-08 14:03 (diff) (minor) Sparti (Kategorie)
• 2005-04-04 17:03 (diff) (minor) Thomas Willerich (wiederhergestellt: Version vom 21:55, 17. Mär 2005)
• 2005-04-04 12:25 (diff) 84.139.190.26 (anon)
• 2005-03-17 19:55 (diff) (minor) Thomas Willerich ({{stub}})
• 2004-12-05 21:20 (diff) 213.209.93.248 (anon) (Link Paradigma eingefügt)
• 2004-12-05 13:14 (diff) Ulrich.fuchs (Und wieder zurück auf eine korrekte Definition.)
• 2004-12-05 13:13 (diff) Ulrich.fuchs (Nicht erkannten Test-Vandalismus rückgängig gemacht)
• 2004-11-10 19:30 (diff) 212.63.46.212 (anon)
• 2004-11-10 17:55 (diff) 80.143.239.187 (anon)
• 2004-11-10 17:43 (diff) 217.232.229.180 (anon) (Leerzeichen nach Komma eingefügt)
• 2004-11-05 11:22 (diff) 195.37.105.2 (anon)
• 2004-10-07 15:55 (diff) Ulrich.fuchs (Mal definiert)
• 2004-07-03 00:08 (diff) Mkleine (der Begriff Objektorientierung sollte auf den Prinzipien-Artikel verweisen)
• 2003-01-27 12:17 (diff) (minor) Aheil (typo)
• 2003-01-27 12:16 (diff) Aheil (-> Objektorientierte Programmiersprache)
• 2003-01-27 11:34 (diff) 172.184.225.62 (anon)

[Bearbeiten] Eigenschaft vs. Attribut

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)

[Bearbeiten] Kritik2

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)

[Bearbeiten] Subtyping

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)

[Bearbeiten] Sind datentypen auch Objekte?

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)