Diskussion:Objektorientierte Programmierung

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Objektorientierte Programmierung“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

Zur Archivübersicht

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 50 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Anwendungsbereiche

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

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

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

Der Artikel stellt es so dar, als erfordere Objektorientierte Programmierung zwingend eine objektorientierte Programmiersprache. Das ist allerdings nicht der Fall. Prinzipiell kann man in vielen Programmiersprachen objektorientiert programmieren. Im einfachsten Fall (statische Methoden, keine Vererbung) reicht es aus wenn eine Programmiersprache Strukturen und Zeiger auf Strukturen unterstützt. Komplexere Sachen, wie Vererbung werden möglich sobald eine Programmiersprache Zeiger auf Prozeduren unterstützt. Also in C ist "manuelle" OOP definitv möglich (vieleicht nicht gerade übersichtlich). Grundsätzlich ist es logischerweise auch in Assembler möglich, denn was ein Compiler Produziert kann man grundsätzlich immer in Assembler ausdrücken(Was vor allem wichtig ist, ist das man Prozeduren hat, die den Speicher verwalten, also quasi neuen Objekten eine Position zuweisen(wobei das Datensegment dadurch auch quasi ein Objekt ist)). Wenn jemand Quellen will, im Handbuch von Turbo Assembler 3.0 ist es gut erklärt, wie OOP auf Assemblerebene aussieht (TASM 3.0 ist zwar selbst eine OOProgrammiersprache(womit sich Borland auch dauernt im Handbuch brüstet(wenn sie sich mal nicht damit brüsten, das sie besser als Microsoft sind[:-)])) jedoch ist da auch gut erklärt was die Direktiven letzendlich für Befehle produzieren). Unter Berücksichtigung dieser Tatsachen sollten auch Ausdrücke wie "nicht können" ind "nicht tun" umgewandelt werden (z.B. "auf die inneren Daten kann nur über Prozeduren zugegriffen werden" in "auf die inneren Daten wird nur über Prozeduren zugegriffen" umwandeln (denn bei manueller OOP ist es durchaus noch Möglich(Was in manchen Fällen sogar eine deutlich geringere Ausführungszeit benötigt(Probleme bei der Portierung kann man umgehen, indem man die Strucktur des Objekts per Header in das andere Programm einbindet, und bei Änderungen an der Klasse die Strucktur anpasst)))).

Vieleicht sollte auch noch erwänt werden dass Objekt-Dateien und Objekte in der OOP nicht nur zufällig den gleichen Namen haben, sondern durchaus einige Gemeinsamkeiten haben. Es kommt in der "normalen" Programmierung durchaus vor, dass man das Datensegment, in einer Quelldatei als "privat" deklariert (oder einfach keine Adressen darin "public" macht) und auch das gesamte Datensegment der Quelldatei nur über die Prozeduren zugreift(der Cache der Dateizugriffsfunktionen in Hochsprachen arbeitet z.B. so). In diesem Fall ist die daraus assemblierte/compilierte Objektdatei sogar ein Objekt im Sinne der OOP. (nicht signierter Beitrag von 79.210.53.245 (Diskussion) 22:07, 20. Jul 2012 (CEST))

Diese These ist falsch. Dass OO schlussendlich zu Maschinen- oder Bytecode wird heisst nicht, dass der daraus resultierende Code selbst objektorientiert ist. Dasselbe gilt auch für die Aussage, dass auf interne (private) Daten sehr wohl zugegriffen werden kann. Das ist nur mit nicht-OO Mitteln wie Introspection oder auf Maschinen- oder Bytecodeebene möglich.

Also zusammengefasst: OO ist nur mit OO Sprachen möglich. Aus OO Code wird (wie überall sonst auch) Maschinen- oder Bytecode. Derselbe Code kann auch anders erzeugt werden, ist aber selbst nicht mehr OO. --Sebastian.Dietrich ✉ 23:32, 20. Jul. 2012 (CEST)

C++ uä zeigen das Gegenteil: Man kann damit O-orientiert programmieren, wird aber nicht durch die Sprache dazu angeleitet. Es fehlt in diesen erstem Sprachen an der Förderung des objektorientierten Denkens; denn ein Paradigma ist zuerst eine Denkart, erst in zweiter Linie wird eine Implementierung mithilfe eines Laufzeitsystems benötigt. Der fehlende Erfolg von Smalltalk liegt so an der mangelnden Konkorrenzfähigkeit der Sprachimplementierung; Die von CalTech angebotene Implementierung zum Preis der Bücher implementierte zwar die Sprache, war aber zur Laufzeit nicht einfach beherrschbar, weil Zeitpunkte, zu denen garbage collection benötigt wurden nicht von außen bestimmt werden konnten und unkalkulierbar in den Tests auftraten. --SonniWP✍ 10:16, 28. Aug. 2012 (CEST)

Klasse und Prototyp

Ein Unterschied wird aus der Beschreibung nicht ersichtlich. --SonniWP✍ 18:07, 27. Aug. 2012 (CEST)