Diskussion:Objektorientierte Programmierung/Archiv/1

message: 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)
replies: text:  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)
replies: text:  "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)
replies: text:  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)
thread_title:  Frage nach dem ''Fragile base class problem'' 

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

message: 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)
replies: text: 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)

text: Das stimmt nicht, denn das hängt von der konkreten Programmiersprache und weiteren Umständen ab. 
Mh 15:01, 16. Feb 2004 (CET)
thread_title:  Auf der Hauptseite nicht mehr benutzte Formulierungen mit gewissem Wert 

message: 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)
replies: text: 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)
thread_title:  Programmierparadigma 

message: Was bringt mir Vererbung - außer unleserlicheren Code? --Abdull 01:46, 19. Mär 2005 (CET)
replies: text: 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)

text: 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)
thread_title:  Vererbung 

message: 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)
replies: text: 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)

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

text: 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)
replies: text: (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)

text: Polymorphie ist eines der fundamentalkonzepte der oop, die frage ob es zwingend ist, scheint mir etwas unsinnig...--Nikolaus  14:28, 29. Apr 2005 (CEST)
thread_title:  Modul... 

message: 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)
replies: text: Lies dir mal diese Diskussionsseite gründlich durch. Steht alles drin. --Johannes2 20:04, 20. Aug 2005 (CEST)

text: 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)
replies: text: Dagegen. Begründung auf dieser Diskussionsseite. (s.o.) --Johannes2 20:04, 20. Aug 2005 (CEST)

text: "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)
thread_title:  Eigene Lemmas für grundlegende Begriffe 

message: 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)
thread_title:  Vererbung und Polymorphie 

message: "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)
thread_title:  Kleine Anmerkung von [[Benutzer:212.204.27.188]] 

message: 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)
replies: text: Für ein so umfassendes Thema wäre wohl eher das Lemma „Objektorientierung“ angebracht, statt „Objekt“, oder? --jpp ?! 00:47, 21. Jan 2006 (CET)
replies: text: 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)
thread_title:  Definition "Objekt" fehlt? 

message: 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)
thread_title:  Artikel in Bezug auf theoretische Aspekte äußerst mangelhaft 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Nachteile der Objektorientierten Programmierung 

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

message: 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)
replies: text: Meine Definition ist mit den Autoren Coad/Yourdon konform, ergänzt um bestehende Passagen. Gruß, ReqEngineer Au weia!!! 11:36, 12. Aug 2006 (CEST)
replies: text: 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)
replies: text: Danke. Deine Expertise als selbsternannter Laie ehrt mich ;-) Dann setz ich das mal rein. Gruß, ReqEngineer Au weia!!! 13:31, 12. Aug 2006 (CEST)
replies: text: 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)
thread_title:  Einleitungssatz unverständlich 

message: 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)
thread_title:  unverständlich 

message: 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)
replies: text: Wie in  (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)

text: 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)
replies: text: Geht in Ordnung, machen wir es so! -- Wilfried Elmenreich 13:57, 14. Aug 2006 (CEST)
replies: text: 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)
thread_title:  Überschneidung mit [[Objektorientierung]] 

message: 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:
# Wo ist denn die Kritik? In meinem Verständnis müste man unter dieser Überschrift doch Probleme oder Grenzen aufzeigen?
# 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)
replies: text: 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)
replies: text: 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)
thread_title:  Kritik2 

message: 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)
replies: text: 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)
thread_title:  Subtyping 

message: Mit kommt die Einleitung recht oberflächlich vor, denn es wird nicht wirklich gesagt was OO von nicht-OO unterscheidet. Vielleicht kann man etwas konkreter werden indem man eine Formulierung ähnlich der folgenden anfügt:
:Kern der objektorientierten Programmierung ist die Einführungen eines aktuellen Objektes (als this, self, oder Current bezeichnet) als Teil des Zustandes während der Ausführung. Im Gegensatz zur nicht-objektorientierten Programmierung, in welcher ein Name (identifier) auf eine globale Variable oder eine feststehende Routine verweist, werden in der objektorientierten Programmierung Variablen und Prozeduren relativ zum aktuellen Objekt ausgewählt.
:Wird eine Variable relativ zum aktuellen Objekt definiert, spricht man zur Laufzeit von einem Feld oder Attribut des Objektes. Dies bedeutet, dass zwei Zuweisungen zum Feld x := 3 auf zwei unterschiedliche Speicherplätze den Wert 3 schreiben, wenn zu Zeit der Ausführung unterschiedliche Objekte aktuelles Objekt waren.
:Des weiteren können Aufrufe von Prozeduren relativ zum aktuellen Objekt deklariert werden. Eine Prozedur, welche relativ zu einem Objekt definiert ist, wird als Methode bezeichnet. Der Aufruf f(3) kann für zwei unterschiedliche aktuelle Objekt unterschiedlichen Code ausführen. Den Vorgang des Verbindens von Aufruf und Code zur Laufzeit wird als dynamisches Binden bezeichnet.
--Schoelle 16:34, 7. Aug. 2007 (CEST)
thread_title:  Einleitung 

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

message: Der Abschnitt "Kritik" könnte noch überarbeitet werden, besonders die beiden letzten Zitate (Stepanov, Dijkstra) sind - ich sags mal so - fragwürdig, besonders aus heutiger Sicht.
zu Stepanov: der Mann ist hauptverantwortlich für die STL, die sicherlich geholfen hat, C++ zu einer der erfolgreichsten objektorientierten Sprachen zu machen - hört sich irgendwie widersprüchlich an. Ausserdem was heisst "mathematisch-begrenzte Betrachtungsweise"? Dass man zum Programmieren logisches Denken braucht? Und der Vergleich mit KI - im Gegensatz zu dieser funktioniert OOP :-)
zu Dijkstra: gerade er müsste es besser wissen, aber OK, der Artikel ist von 1994, da steckte OOP ja eh noch in den Kinderschuhen. Nur spätestens dann, wenn hochkomplexe Softwareprojekte im Industriellen Umfeld zu managen sind, wird man "Schlangenöl" wie z.B. Software Engineering oder OOP zu schätzen wissen, die konsequente Nutzung dieser Strukturen kann schon das eine oder andere Desaster (siehe Programmierfehler) vermeiden helfen.
Mittlerweile ist OOP Standard, und statt des Abschnittes "Kritik" fände ich etwas in der Art "Vor- und Nachteile", bezogen auf jeweilige Einsatzzwecke, Soft- und Hardwareumgebungen nützlicher (man kann natürlich erwähnen, dass OOP nicht in jedem Fall sinnvoll ist, Microcontrollerprogrammierung etwa), aber allein aus NPOV-Sicht ist der Kritik-Abschnitt doch eher einseitig. --Ayanami rei 16:48, 23. Dez. 2008 (CET)
thread_title:  Kritik3 

message: Self sollte Nummer eins in der Liste der Prototyp basierte Sprachen sein (da es vor den beiden anderen Sprachen entwickelt wurde und das Konzept als eine der ersten Sprachen als Basis eines Objektsystemes verwendete).
Smalltalk ist ein besseres Beispiel für eine Sprache mit first-class Klassen als Objective-C, da es den Ansatz "alles ist Objekt" hat und damit diese Eigenschaft deutlicher ist und tiefer in der Sprache verankert ist (Objective-C hat ja nicht einmal Integers, die eine Klasse haben). Außerdem hat Smalltalk die sauberere Syntax und das bessere Sprach Design.
Zitat: "Klassen werden in der Regel in Form von Klassenbibliotheken zusammengefasst, die häufig thematisch organisiert sind. So können Anwender einer objektorientierten Programmiersprache Klassenbibliotheken erwerben, die den Zugriff auf Datenbanken ermöglichen."
Der Punkt der Klassenbibliothek ist nicht, dass man sie erwerben kann, denn
1. es gibt freie Datenbankbibliotheken
2. der Punkt der Bibliothek ist es sie zu verwenden nicht sie zu erwerben oder zu installieren
Außerdem passt das Wort "thematisch" nicht zu Organisationsstruktur. Ich denke, dass "nach funktionalen Gruppen organisiert" dies besser beschreibt.
Des weiteren ist es nicht speziell für Klassenbibliotheken, dass die eine solche Organisationsstruktur haben, auch prozedurale Bibliotheken sind nach Funktionalität sortiert, es gibt auch prozedurale Bibliotheken, die den Zugriff auf eine Datenbank erlauben. Es sollten deutlicher die Unterschiede einer Klassenbibliothek zu einer prozeduralen Programmbibliothek ausgearbeitet werden, insebsondere sollte auf den Begriff Framework eingegangen werden.
Der Abschnitt verbindet Techniken aus ganz verschiedenen Abstraktionsebenen, dies verwirrt.
Insgesamt sollte der Abschnitt Grundlegenend umgearbeitet werden, es sollte klar zwischen Software Design (Design Patterns, UML, ...), Sprachdesign (Prototype-Sprachen, Sprachen mit First-Class Klassen, ...) und Code-Organisation (Klassenbibliotheken, Frameworks) unterschieden werden.
--Sebastian42 21:12, 30. Okt. 2009 (CET)
thread_title:  Techniken-Abschnitt 

message: Die Modifier verhindern den Aufruf einer z.B. privaten (private) Methode nicht. Da es immer Möglichkeiten gibt diesen "Schutz" zu umgehen. Bei C/C++ reichen hier Pointer auf die entsprechenden Funktionen, bei Java ist dies per Reflection-API möglich. Diese Modifier haben hier allein die Funktion Variablen und Methoden, die nicht zu einer öffentlichen API gehören, zu verbergen, bzw. es ist Aufgabe des Compilers dem Programmierer vor dem Aufruf/Änderung von geschützten Bereichen zu warnen und gegebenenfalls (je nach Einstellung) nicht zu kompilieren.
Es ist also im Grunde nichts weiter als eine zusätzliche Information an den Programmierer der fremden Code (von einem Mitarbeiter geschrieben oder fremden Bibliothek) verwenden will. Hierbei soll er davon abgehalten werden Funktionen/Variablen der nicht öffentlichen API zu benutzen, da dies Nebeneffekte für den Fremdcode haben könnte, die vom Schreiber der API nicht beabsichtigt waren und vom Verwender aufgrund fehlenden Quellcodes nicht eingeschätzt werden können. "Man hätte in der Dokumentation darauf hinweisen können, dass solche API-Bestandteile nicht genutzt werden dürfen, aber so warnt auch der Compiler davor." Siehe auch  und  -- 10:30, 15. Okt. 2009 (CEST)
thread_title:  Methoden und Modifier 

message: Unter dem Punkt "Kritik" steht als erstes :
"Luca Cardelli untersuchte für das DEC Systems Research Center die Effizienz von OOP-Ansätzen mit den Metriken Programmablaufgeschwindigkeit (economy of execution), Compilegeschwindigkeit (economy of compilation), Entwicklungseffizienz für große und kleine Teams (economy of small-scale development und economy of large-scale development) und die Eleganz des Sprachumfangs selbst (economy of language features).[1]"
Warum steht da denn nicht, zu welchem Ergebniss er kommt ? Oder soll mit dem Eintrag angedeutet werden, das OOP in all' den genannten Punkten gar nicht so gut abschneidet ? -- 80.171.43.158 12:35, 12. Apr. 2010 (CEST)
replies: text: ein berechtigter Einwand. Und ausserdem bedeutet "economy" nicht "Eleganz". --Herbert Klaeren 09:57, 14. Apr. 2010 (CEST)
thread_title:  Kritiken 

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

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

message: Die Behauptung im ersten Satz dieses neuen Abschnitts ist sehr zweifelhaft und durch nichts belegt. Als Fachmann für Programmiersprachen glaube ich nicht daran, dass das wirklich stimmt. Wiederverwendbarkeit von Code war wirklich nicht das primäre Ziel bei der Entwicklung von OOP. Der Rest des Abschnitts ist schwer verständlich und sollte in dieser Form nicht stehenbleiben, das verwirrt nur. Ich habe jetzt erst mal darauf verzichtet, den neuen Abschnitt ganz zu löschen, aber wenn der nicht entscheidend verbessert wird, muss ich das in Zukunft sicher mal tun.  --Herbert Klaeren 11:14, 5. Jul. 2010 (CEST)
replies: text: hm, hab mir das mal angeschaut, wie wär's den so: "Ein der häufig gehörten Verheissungen (Vorzüge?) des Objektorientierten Paradigmas ist bessere Wiederverwendbarkeit und Wartbarkeit ..." Zumindest ist das einer der heutzutage häufig gehörten Vorzüge, Quellen dazu: http://www.drdobbs.com/184415594 Reusability is one of the great promises of object-oriented technology. ... Oder im geschichtlichen Kontext: http://www.developer.com/java/other/article.php/3493761/The-Evolution-of-Object-Oriented-Languages.htm Simula. By the 1960s, programmers realized that programming systems needed to be broken up into small, manageable pieces. The introduction of Simula-67 brought with it the first true programming object, classes, and a form of inheritance; therefore, Simula is an important milestone in any discussion on O-O programming languages ... an der Sache mit dem Kontrollfluss könnte was dran sein, wie man das aber deutlicher zeigen kann... hmmm, sprachlich argumentieren wie in der 2. Quelle ? : Steve Yegge’s rather famous post, “Execution in the Kingdom of Nouns” has probably done more to frame and influence my thoughts about object-oriented programming (OOP) than anything else out there. <snip> I finally got a handle on why I feel that multithreaded work is significantly more difficult than it needs to be: the noun-oriented nature of the languages that I have written multithreaded code in.--141.52.232.84 18:25, 6. Jul. 2010 (CEST)
replies: text: ja, das sieht gut aus, ich hab nur noch ein paar Kleinigkeiten getunt. --Herbert Klaeren 19:10, 8. Jul. 2010 (CEST)
replies: text: Danke, finde ich auch, besser nun. --141.52.232.84 13:17, 9. Jul. 2010 (CEST)
thread_title:  OOP und Kontrollfluss 

message: Die Seite Membervariable hat eine Weiterleitung auf diese Seite, ohne das der Begriff hier auch nur einmal erwähnt wird.
--Wookie 13:41, 27. Jun. 2011 (CEST)
replies: text: Stimmt, zusammen mit Member, was als Wort zwar genau einmal auftaucht, aber mit anderer Verwendung als man es erwarten würde. Ich halte eine Weiterleitung auf Klasse (Programmierung) für sinnvoller, wo dann die Begriffe gleich in der Einleitung erklärt werden könnte (wie bei :en:Class (computer programming)). Hier könnte man sie auch nochmal im Abschnitt Klasse erwähnen. --Zahnradzacken 16:53, 27. Jun. 2011 (CEST)
thread_title:  Weiterleitung von [[Membervariable]] 

message: In diesem Artikel kommt das Wort Ereignis nicht vor. Fehlt da nicht was - wenigstens als Synonym (oder ähnlich) zu einem anderen OO-spezifischen Ausdruck? --VÖRBY 13:16, 26. Nov. 2011 (CET)
replies: text: Zumindest erwähnen sollte man dass in der Praxis die OOP und Ereignisorientierte Programmierung gut kombinierbar sind.--Avron 21:08, 26. Nov. 2011 (CET)
replies: text: Naja Events werden halt je Sprache unterschiedlich abgebildet, mal mit FunctionPointern, mal mit Observern --Sebastian.Dietrich  ✉ 21:26, 26. Nov. 2011 (CET)
thread_title:  Ereignisse? 

message: Mich würde Anwendungsbereiche für OOP interessieren. Wo kommt sie mit welcher Intention zum Einsatz? --Das Robert      .... gibs mir! 20:25, 7. Feb. 2012 (CET)
replies: text: eine gute Frage... Das erinnert mich wieder an die Diskussion über einen breiteren Rezeptions- und Evaluationsabschnitt bzgl. der Konzepte, Versprechungen und Ergebnisse der OOP, gebildet aus der Rezeption im akademischen wie professionellen Bereich. Die Akzeptanz und das Verständnis der OOP ist durchaus Wandel unterworfen ... ach ja hier ist das Material noch im  Diskussions-Archiv 2010 bei dem man beginnen könnte. gruss Shaddim (Diskussion) 17:29, 27. Mai 2012 (CEST)
thread_title:  Anwendungsbereiche 

message: Ein Unterschied wird aus der Beschreibung nicht ersichtlich. --SonniWP✍ 18:07, 27. Aug. 2012 (CEST)
replies: text: Änderungen am Prototyp werden dynamisch am abgeleiteten Objekt wirksam, wägtrnd die Ablritimh rinrt Klasse statisch wirkt. --SonniWP✍ 20:15, 28. Aug. 2012 (CEST)
thread_title:  Klasse und Prototyp