Delphi objektorientiert?

[Der_Unwissende]

Hi,
ich möchte mal kurz anmerken, dass ihr euch so noch ewig streiten könnt, was OOP ist und was nicht (und keiner von euch hat absolut Recht/Unrecht). Es gibt einfach keine genaue Definition wann etwas OOP ist und wann nicht mehr. Ähnlich wie Logische, Funktionale, Imperative, ... Programmierung ist auch die OOP nur ein Konzept dass einige Ansätze vorgibt, aber eben auch nicht mehr.

Natürlich haben C++, Delphi, Java, ... streng genommen nur die Möglichkeit Eigenschaften der OOP zu benutzen, aber sind (streng genommen) keine OOP-Sprachen.
Ich weiß ehrlich gesagt nicht, warum dass zweite O hier so betont wird. IMHO hat es nichts mit den Objekten der Programmiersprachen zu tun, sondern es bezieht sich lediglich auf das Konzept hinter OOP. Es ging bei OOP eigentlich nur darum, das "reale Leben" nachzubilden. Und wenn man sich anguckt wie das Funktioniert (natürlich stark vereinfacht und abstrahiert), dann kommt man schnell dazu dass es eine Welt gibt, die von Objekten bevölkert wird. Diese Objekte können sich kennen und miteinander kommunizieren, sie können Eigenschaften weitergeben und nicht ausserhalb dieser Welt leben. Zudem ist wohldefiniert, wie einzelne miteinander kommunizieren. Sehr grob ist das wohl das, was das Objekt Orientiert ausmacht.

Wo sich übrigens alle Definitionen weitgehend einig sind ist, dass OOP folgendes in den Vordergrund stellt:

• Abstraktion
• Vererbung
• Kapselung
• und irgendwas was mir gerade nicht einfällt

Jedenfalls existiert ein Objekt immer nur für eine bestimmte Zeit (max. von Beginn bis Ende des Programms). Jedes Objekt hat Eigenschaften, von denen aber möglichst wenig bekannt sein sollte. Es soll nur bekannt sein, was ein Objekt macht, nicht wie. Ein Objekt kann auf eingehende Nachrichten reagieren. Dabei ist eine Nachricht übrigens nur ein Begriff, nicht gekoppelt an eine Interpretation wie diese Nachricht aussieht.
Objekte können Eigenschaften vererben und geerbte Eigenschaften verändern (also anders reagieren).
Das war es eigentlich auch schon.

Ob Objekte intern eine Prozedur aufrufen oder nicht ist vollkommen egal. Aus Sicht der OOP interessiert das keinen, das Objekt ist schließlich nur eine Kapselung seiner Funktionalität. Anders als bei Prozeduralen ansätzen sollte ich bei einem Objekt gar keine Möglichkeit haben, eine prozedur einfach aufzurufen. Ich habe aber durchaus die Möglichkeit mit einem Objekt zu kommunizieren. Durch die Kapselung weiß ich also was ich dem Objekt mitteile und was ich als Antwort bekomme. Natürlich sieht das in einigen Umsetzungen so aus, wie der Aufruf einer Prozedur, die zu einem Objekt gehört, aber das ist doch nur eine Umsetzung.

Wichtig ist, dass OOP ein ganz anderen Ansatz verfolgt als Prozedurale Programmierung. Das heißt aber nicht, dass sie nichts gemeinsam haben dürfen (Haskell kennt auch while-Schleifen, für mich bleibt es Funktional). Aber alles was nicht OOP ist, muss doch auch nicht automatisch Prozedural sein.

Was jedenfalls bleibt ist der Fakt, dass es alles nur Auslegungssache ist. Meines Erachtens gibt es keine einzigst wahre und allgemeingültige sowie vollständige Definition von OOP und damit auch kein Argument wann etwas definitiv nicht mehr OOP ist. Es ist halt so, dass (sicher auch durch den Modeeffekt von OOP) viele Sprachen unsaube Konzepte mischen (immerhin kann man in Delphi sowohl komplett iterativ als auch weitestgehend OO programmieren oder es einfach mischen). Und um mal von Delphi wegzugehen, Python (sicherlich, eine interpretierte Sprache, aber egal), kann z.B. auch Prozedural oder mit dem Lambda Funktional arbeiten...

Ach ja, zu meinen Anmerkungen dass OOP Modeerscheinung ist möchte ich auch noch sagen, dass ich es nicht abwertend meine. Ich mag die OOP (egal wie streng man sie nun auslegt) und sie hat durchaus ihren Sinn. Wie schon häufiger gesagt, nicht immer, nicht überall. Man sollte nur Bedenken wie alt die Ansätze der OOP sind (> 20 Jahre) und das es die ersten 10 Jahre kaum Interesse an diesen Konzepten gab (nicht so breit wie heute). Natürlich lag es daran, dass Abstraktion immer mit Overhead verbunden ist, der für damalige Verhältnisse (Rechenzeit, Speicherplatz,...) zu teuer war. Aber ich persönlich finde, dass etwas zu stark zum bejubbeln der OOP geneigt wird, da viele OOP schreien ohne verstanden zu haben, dass es um was anderes als nur Klassen / Objekte und Vererbung geht.

Gruß Der Unwissende

Edit : Delphi statt list verwendet, peinlich

[Nils_13]

Zitat von Hansa:

Zitat von Nils_13:

Aber Pascal war es noch nie, ich hab das heute noch, außer Codes eintippen ist da nichts möglich.

Was hast du heute noch ? TP 5.5 war bereits objektorientiert. Und genau da liegen die Grundlagen vom heutigen Delphi. Code eintippen hat mit OOP jetzt aber überhaupt nichts gemeinsam. Ich glaube, hier wird sogar die IDE mit OOP verwechselt. Die erste könnte ich (relativ) leicht verschmerzen, das zweite aber nicht !

Ich hab das TP 7. OOP ? Nein !

[malo]

Zitat von Nils_13:

Ich hab das TP 7. OOP ? Nein !

Also, mein TP 5.5 hat OOP. Komisch

[Chewie]

Zitat von Der_Unwissende:

• Abstraktion
• Vererbung
• Kapselung
• und irgendwas was mir gerade nicht einfällt

Meinst du in diesem Zusammenhang vielleicht Polymorphie und späte Bindung?

[alzaimar]

Zitat von Horst_59:

Zitat von alzaimar:

Merke: Auch ein Prozeduraufruf ist eine Form der Kommunikation.

Mir ist nicht klar, wer bei einem Prozeduraufruf kommuniziert?

Wer? Die aufrufende Instanz. Sonst ist ja keiner da. Während Objekte 'leben' (nun ja) und im übertragenen Sinne auch passiv kommunizieren können, indem sie warten, bis jemand sie endlich mal über eine ihrer Methoden aufruft/Nachrichten versendet, ist bei der skalaren, alteingesessenen prozeduralen Sichtweise immer der Aufrufende der, der kommuniziert. und zwar mit dem Aufgerufenen.

OOP definiert die *Sichtweise* einer Problemlösung, nämlich, das ich die Subsysteme des Problems (ex Units) in logisch, syntaktisch und sematisch zusammenhängende Entitäten fasse und immer als Ganzes mit ihnen arbeite. Das macht komplexe System naturgemäß übersichtlicher, aber kleine u.U. eben nicht.

Du kommst aus einer ganz anderen Ecke, die ich, nebenbei bemerkt, äußerst interessant finde. Hier zeigt sich mal wieder, das das Gegenteil einer Wahrheit durchaus wieder eine Wahrheit sein kann, weil es, im Gegensatz zur boolschen Logik im richtigen Leben und bei Diskussionen viele 'True' Zustände geben kann. Ein Umstand, der selbst mit OOP nicht in einen Rechner zu pressen ist.

Na denn...

[edit] Dieser Thread ist mit Abstand das Beste, was ich hier oder im DF jemals gelesen habe. Das hier ist ein Diskurs auf hohem Niveau! [/edit]

[Hansa]

Zitat von alzaimar:

[edit] Dieser Thread ist mit Abstand das Beste, was ich hier oder im DF jemals gelesen habe. Das hier ist ein Diskurs auf hohem Niveau! [/edit]

Du meinst doch hoffentlich nicht so was wie das:

Zitat von Nils_13:

Ich hab das TP 7. OOP ? Nein !

Bei so was fehlt echt jede Gesprächsgrundlage. Der Thread geht vollkommen an der Realität vorbei. Äh, wann war nochmal die Marslandung ?

[alzaimar]

Nee, aber viele andere Meinungen zu dem Thema sind wirklich fundiert und ausführlich dargelegt. Das dabei auch flachere Beiträge sind, liegt in der Natur eines Forums.

[choose]

Hui, hier hat sich eine Menge bewegt.

Zitat von alzaimar:

Zitat von Horst_59:

Mir ist nicht klar, wer bei einem Prozeduraufruf kommuniziert?

Wer? Die aufrufende Instanz. Sonst ist ja keiner da. [..] bei der skalaren, alteingesessenen prozeduralen Sichtweise [ist] immer der Aufrufende der, der kommuniziert. und zwar mit dem Aufgerufenen.

ich würde dem auch nicht zustimmen, alzaimar. Bei einer prozeduralen Betrachtung gibt es im engeren Sinne keine Kommunikation zwischen Beteiligten. Es gibt nur Logik, die der Reihenfolge nach abgearbeitet wird und sich (in Single-Threaded-Anwendungen) jeder Zeit an genau einem Ausführungsschritt befindet, sowie Daten, die von dieser Logik manipuliert werden. Streng genommen gibt es für ein prozedurales Programm (anders als zB bei funktionaler Programmierung) keine andere Möglichkeit, sinnvoll zu agieren, als Daten zu verändern (Seiteneffekt).

Bildlich könnte man sich prozedurales Vorgehen vielleicht mit Hilfe eines Gärtners vorstellen (aktueller Ausführungspunkt), der Wege durch einen Park nimmt (Ausführungsplan), um Pflanzen zu beschneiden (verändern von Daten). Weder die Pflanzen kommunizieren miteinander und (abgesehen von etwaigen Selbstgesprächen) Kommuniziert der Gärtner nicht auf einer lingualen Ebene mit den Gewächsen (bitte jetzt kein metakommunikatives Axiom: "Man kann nicht nicht kommunizieren"). Hat der Gärtner seinen Gang beendet und schlussendlich jeden verwinkelten Abschnitt des Parks über die vielen Verzweigungen genommen, kann er nach getaner Arbeit auf sein Werk blicken.

In einer Multi-Threaded-Anwendung würden mehrere Gärtner gleichartige Arbeiten erledigen, eine direkte kommunikation ist allerdings auch hier (prozedural) nicht möglich. Über Hilfsmittel wie "an jedem Weg, den ich bearbeitet habe, hinterlasse ich ein Zeichen" oder "Gänge, die schon bearbeitet wurden, betrete ich nicht" bzw. "es gibt einen Arbeitsplan, der Aussschließt, dass wir uns in die Quere kommen" werden die Arbeiten der gleichzeitig Agierenden abgestimmt.

Bei einem objektorientierten System wird sowohl vom konkreten Empfänger einer Nachricht als auch von der Art der Durchführung einer Operation/Nachricht abstrahiert. Ein denkbares Szenario könnte dann so aussehen: Gärtner an Park "mach Dich schön".
Der Park wiederum könnte sich nun an all seine Bestandteile (Pflanzen) wenden und sie ihrerseits bitten, sich in Schale zu werfen. Er hat keine exakte Vorstellung, welche Elemente konkret im Laufe der Zeit in ihm gewachsen oder sonstwie entstanden sind, verlässt sich darauf, dass jedes Element im Park weiß, wie es sich "schön machen" kann. Wenn später auch Skulpturen aufgestellt werden sollten, braucht weder der Park noch der Gärtner sein Verhalten ändern. Beide sagen nur "mach Dich schön". Erhält eine Skulptur direkt oder indirekt die Aufforderung, könnte sie einfach eine Gärtnerei anrufen

[alzaimar]

Zitat von choose:

ich würde dem auch nicht zustimmen, alzaimar. Bei einer prozeduralen Betrachtung gibt es im engeren Sinne keine Kommunikation zwischen Beteiligten.

Im engeren Sinne natürlich nicht, davon sprach ich aber nicht. Du betrachtest "Kommunikation" als etwas Bidirektionales, bei dem beide Partner unabhängig voneinander einfach drauflosquatschen, so wie in einem verteilten System eben üblich. Die prozedurale Kommunikation findet aber, metaphysisch gesehen, sehr wohl statt, wenn auch etwas einseitig:
Ich befehle dem Unterprogramm, das es etwas erledigen soll und, wenn es fertig ist (oder auch früher, per Exception), bekomme ich eine Rückmeldung, das es geklappt hat, oder nicht. Wenn ich die Worte 'befehle' und 'Rückmeldung' verwende (wie in prozeduralen Sprachen üblich: 'Commands', 'Returns' ...) , sollte das doch schon Beleg genug sein, das hier eine 'Kommunikation' stattfindet, nur ist sie etwas langweilig, weil es immer nur einen Aktiven gibt, nämlich den (logischen) Program-Counter.

Das hat aber Nicht viel damit zu tun, ob Delphi nun OO ist, oder nicht, denn OO macht sich ja nun mal nicht an der Tatsache fest, das Speicherblöcke Nachrichten austauschem, was im Endeffekt ja auch nichts anderes als Prozeduren sind (Aber ebenso könnte man Menschen die Intelligenz abstreiten, weil ja alles auf einfache chemische Reaktionen hinausläuft).

Ich würde deine Sichtweise nicht als Merkmal der OOP, sondern eher als Merkmal verteilter Systeme definieren. Die bloße Tatsache, das Smalltalk mit Nachrichten rumhantiert, gibt ihr ja nicht automatisch den alleinigen Besitzanspruch für die Eigenschaft 'OO'.

Ich würde die Definition im Wiki mal als Grundlage nehmen, und danach sind es nicht die Nachrichten, die OO ausmachen, sondern, wie ich bereits sagte, die Sichtweise und die Art und Weise der Implementierung.

[Der_Unwissende]

Zitat von alzaimar:

Ich würde deine Sichtweise nicht als Merkmal der OOP, sondern eher als Merkmal verteilter Systeme definieren. Die bloße Tatsache, das Smalltalk mit Nachrichten rumhantiert, gibt ihr ja nicht automatisch den alleinigen Besitzanspruch für die Eigenschaft 'OO'.

Natürlich ist Kommunikation nur eine Notwendig Bedingung für OOP, keine Hinreichende und natürlich ist Kommunikation nur eine Bedingung.

Fakt ist, dass Delphi Programme Imperativ sein können. Der Beweis, dass Delphi aber nicht imperativ ist liegt in jedem TThread (ausser dem der Hauptanwendung/Main-Thread, wie auch immer). Den die imperative Programmierung geht definitiv von einer CPU aus, die sequenziell arbeitet (und es gibt ne Menge nicht sequentieller Programme in Delphi).

Fakt ist, dass Delphi Programme OO sein können. Der Beweis, dass Delphi aber nicht OOP ist, liegt in jeder dpr-Datei, die imperativ arbeitet (oder mindestens zu einem rein imperativen Programm umgeformt werden kann).

Fakt ist also, Delphi ist weder OOP noch Imperativ. Frage geklärt.

Die Sache ist und bleibt doch nun mal, wie genau ist OOP definiert. Was im Wiki steht ist natürlich keine allgemeingültige Definition (das Bedingt die Idee des Wikis).
Aber bei OOP handelt es sich nur um ein Programmierparadigma, dass wie bereits erwähnt eine bestimmte Sicht auf Probleme ermöglicht und diese damit auf eine Bestimmte Art und Weise löst. Da habeb also alle Recht, die das hier (denke es war mehrfach, zuletzt jedenfalls von alzaimar) gesagt haben.

Das Smalltalk OO ist liegt nicht an der Kommunikation zwischen Objekten sondern vielmehr daran, dass ein Smalltalk Programm nur die Kommunikation von Ojekten ermöglicht. Mehr ist, soweit ich weiß, nicht möglich. Es ist vorallem nichts anderes mit Smalltalk möglich.
Natürlich dürfen auch in anderen Programmierparadigmen Objekte existieren und miteinander Kommunizieren. Aber solche Paradigmen erfüllen schon mal einen Teil der Anforderungen an die OOP (da ist eine Verwechslung schon mal leicht).

Da OOP nur ein Paradigma ist, kann man nicht wirklich sagen dass eine Sprache OOP ist (auch wenn ich es hier schon mehrfach getan habe). Das liegt aber eher daran, dass wir doch dazu neigen unsere Sätze kontexsensitiv bilden (unsere Programme eher kontextfrei).
Natürlich kann man ein Paradigma nur einhalten oder nicht. Natürlich muss es die Möglichkeiten geben das Paradigma einzuhalten oder zu verletzen. Also kann eine Sprache nie OOP sein, wenn z.B. Kapselung unmöglich ist, sie muss wiederum OOP sein, wenn alle Bedingung immer erfüllt sind. Kann man das Paradigma erfüllen oder verletzen, ist keine Festlegung für die Sprache im allgemeinen sondern nur noch für einzelne Programme möglich.

Und damit sage ich es nochmal, Delphi ist weder OOP noch nicht OOP (oder wer möchte es ist gleichzeitig OOP und nicht OOP), hängt nur noch von der Auslegung (und meinen Denkfehlern) ab.

... und entspricht nahezu dem was alzaimar als letzten Satz schrieb, hm, bin wohl ein Letzes-Wort-Fetischist?!