Delphi objektorientiert?

[mschaefer]

Moin zusammen,

geniessen wir den Sonntagabend und nehmen wie meinetwegen den Duden als Grundlage (und nicht die Kommission..?).
Das Orientierte scheint auch geklärt. Das objektorientiert Programmierung sinnvoll ist hat Hansa schon klargestellt.

Das Fahrzeugbeispiel von Choose soll deutlich machen, dass Sachverhalte ähnlich aussehen, aber lediglich einen komplemntären Enwicklungsweg haben können, da letzlich gleich Aufgaben gelöst werden sollen. Und dass Objekte manchmal Gemeinsamkeiten haben und nicht voneinander abgeleitet sind, auch dies ist dem Beispiel zu entnehmen. Ja dieses Faktum ist angekommen!


Jetzt gehen wir mal an den Knackpunkt:
----------------------------------------------------------------------------------------------------------------------

• Gemeinsam ist Objekten und Prozeduen die Behandlung von Variablen.
  An der Eigenschaft kann man also keine Unterscheidung treffen, was es ist.
  
• Die Monofunktionlaität ist eine typische Eigenschaft von Prozeduren, die ihre Fähigkeit, ihre Funktionalität auf andere Daten von Routinen und/oder Objekten anzuwenden natürlich selbst mitbringt. Ein Objekt kann auch nur eine Funktionaltiät haben. Bei Monofunktionalität des Objektes, ist es also letzlich nicht von der Prozedur/Funktion zu unterscheiden.
  
• Die Multifunktionalität mit mehreren Zugriffspunkten kennzeichnet eindeutig ein Objekt und unterscheidet es von der Routine (Prozedure oder Funktion).
  
• Ein Objekt kann im Gegensatz zu einer Routine um Funktionalität erweitert werden, durch Ableitung.

----------------------------------------------------------------------------------------------------------------------

Das Print Beispiel:

1. Print hat die Eigenschaft eine Variable empfangen zu können.
2. Print hat nur eine Monofunktionalität ohne weitere Einstellungsmöglichkeiten und Ergänzungsroutinen nach aussen.

FAZIT
Es kann wie jede Prozedur als Simpleobjekt aufgefasst werden. Das ist eine Frage der Philosophie zu der Mathematik und damit die Informatik mit ihren geschlossenen Modellen annerkannt gehören. Das widerlegt weder Choose, aber nun mal auch nicht meine Sicht das Ding als polnisch notierte Prozedur, wie in "Forth" üblich, aufzufassen! Mit dem Beispiel kann es aufgrund der Monofunktionalität und zudem ohne sichtliche Erweiterungsmöglichkeit keine letzliche Klärung geben, ob es ein Objekt ist.

----------------------------------------------------------------------------------------------------------------------


Hallo Choose dass ist übrigens sehr interessant argumentiert. In Deinem Modell ist Print das Objekt das seine Funktionalität durch die Übergabe einem weiterem Objekt weitergibt, dass diese Methode oder Funktionalität bisher nicht hatte, aber widerlegt bin ich mit meinem trivial kompartimentorientierten Ansatz nun noch nicht. Dass Ding bleibt knifflig.

Viele freundliche Grüße // Martin

[Nils_13]

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

[malo]

Zitat von Nils_13:

Delphi ist Objektorientiert.

Wenn du den Thread gelesen hättest, wüsstest du, dass das Unsinn ist.

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 verstehst du unter "Pascal"? Meinst du das Pascal von Niklaus Wirth, oder Turbo Pascal von Borland, oder FreePascal, oder Chrome... ? Pascal bezeichnet mitlerweile viele Sprachen

Niklaus Wirth hat jedoch nie an Objektorientierung gedacht. Und soweit ich weiß, gab es damals in den 60er Jahren auch noch keine Sprachen mit OOP-Sprachfeatures...

[Nils_13]

Zitat von malo:

Zitat von Nils_13:

Delphi ist Objektorientiert.

Wenn du den Thread gelesen hättest, wüsstest du, dass das Unsinn ist.

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 verstehst du unter "Pascal"? Meinst du das Pascal von Niklaus Wirth, oder Turbo Pascal von Borland, oder FreePascal, oder Chrome... ? Pascal bezeichnet mitlerweile viele Sprachen [/quote]
Nein unter Pascal verstehe ich Turbo Pascal. Das stimmt, muss ich hier erst die neuste Version hochladen oder was soll der Quatsch. Delphi ist die Objektorientierte Fortsetung von Turbo Pascal. Aber man kann da noch Pascal programmieren. Delphi und Pascal ist eh fast das Selbe.

[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 !

[Horst_59]

Servus,

eine sehr interessante Diskussion, die hier aufgekommen ist.

Zitat von mschaefer:

Das Print Beispiel:

1. Print hat die Eigenschaft eine Variable empfangen zu können.
2. Print hat nur eine Monofunktionalität ohne weitere Einstellungsmöglichkeiten und Ergänzungsroutinen nach aussen.

FAZIT
Es kann wie jede Prozedur als Simpleobjekt aufgefasst werden. Das ist eine Frage der Philosophie zu der Mathematik und damit die Informatik mit ihren geschlossenen Modellen annerkannt gehören. Das widerlegt weder Choose, aber nun mal auch nicht meine Sicht das Ding als polnisch notierte Prozedur, wie in "Forth" üblich, aufzufassen! Mit dem Beispiel kann es aufgrund der Monofunktionalität und zudem ohne sichtliche Erweiterungsmöglichkeit keine letzliche Klärung geben, ob es ein Objekt ist.

Print ist in dem Beispiel eine Nachricht, die einem Objekt mit dem Namen i geschickt wird (wodurch print selbst wiederum ein Objekt ist, aber das ist smalltalkspezifisch). Da die Wirkung dieser Nachricht ausschließlich vom Empfänger der Nachricht und dessen "Reaktion" abhängt, kann keinesfalls von Monofunktionalität gesprochen werden (Print könnte beispielsweise in die Konsole oder in eine Datei schreiben).

Monofunktionalität schließt ein, dass jederzeit klar ist, was passiert, also bereits zur Übersetzungszeit. Objekte hingegen sind polymorph, als kann erst zur Laufzeit entschieden werden, welcher Code ausgeführt wird und welche Wirkung entsprechend ein Methodenaufruf hat. Dies kann nicht mit Hilfe von Prozeduren erreicht werden.

Gruß
Sebastian

[malo]

Zitat von Nils_13:

Nein unter Pascal verstehe ich Turbo Pascal. Das stimmt, muss ich hier erst die neuste Version hochladen oder was soll der Quatsch. Delphi ist die Objektorientierte Fortsetung von Turbo Pascal. Aber man kann da noch Pascal programmieren. Delphi und Pascal ist eh fast das Selbe.

Wie kommst du auf "neuste Version"?
Mit TP 5.5 wurden Objekte in Delphi eingeführt. Und TP wurde bis 7.0 weiterentwickelt.

Übrigens solltest du bedenken, dass du grundsätzlich vorsichtig sein solltest mit Äußerungen wie "Delphi und Pascal ist eh fast das Selbe". Denn Delphi hat mit Pascal kaum noch was gemeinsam. Lediglich der Aufbau der Sprache und die grundlegenden Strukturen sind erhalten geblieben.
Aber alles was mit Units, Klassen, Fenstern etc. zu tun hat, war in Pascal undenkbar
Das war eine relativ primitive Sprache. Erst durch Borland wurde die Sprache attraktiv.
Und Turbo Pascal <> Pascal! Da liegen auch noch Welten zwischen
Ab TP 5.5 wird die Sprache jedoch nicht mehr Pascal genannt, sondern i.d.R. Object Pascal, durch die Objektorientiertung.
Object Pascal kann man aber mit der Delphi-Language vergleichen. Aber Pascal ist eigentlich nicht vergleichbar mit Delphi...

Und noch einmal zum Mitschreiben: Delphi ist nicht objektorientiert. Sie hat höchstens objekteorientierte Spracheigenschaften. Objektorientiert ist sie aber nur, wenn man mit ihr nur OOP programmieren kann, und die prozeduale Programmierung nicht möglich ist.
Daher solltest du dir nochmal den Thread durchlesen

[alzaimar]

Und ich dachte immer, objektorientiert heisst nur, das die Implementierung eines Problems nicht an einer klassischen API und dem Unitkonzept festgemacht wird, sondern an Objekten (woher kommt das 'orientiert' denn sonst?).

Ob denn Objekte nun Nachrichten austauschen, oder einfach nur Objekte mit Methoden und Eigenschaften sind, dürfte auch unerheblich sein. Und das ich mit einer OOP-Sprache nun keine Prozeduren programmieren kann, ist doch wohl auch Quatsch. Natürlich gibt es Sprachen, die das nicht erlauben, das heisst aber nicht, das die dann die OO-Eigenschaft für sich reserviert haben. Man sollte mal unterscheiden, zwischen Sprachen, die das OOP-Konzept auf die Spitze treiben, und denen, die noch andere Sprachkonstrukte anbieten. Wieso sollen denn nicht beide OO sein?

Und das Delphi deshalb nicht OO ist, weil es hier im Thread steht, ist ja wohl der größte Witz. Nicht, das ich was gegen die sehr fundierten Ausführungen sagen will, aber die Zugehörigkeit einer Programmiersprache zu einer Klasse macht sich nicht an den Aussagen Einzelner fest.

Letztendlich ist eh alles Prozedural, aber die Herangehens- oder Sichtweise (eben 'Objektorientiert', 'Prozedural' oder 'Serviceorientiert') ist unterschiedlich.

Wenn ich einem Objekt eine Nachricht schicken muss, damit sie sich um eins erhöht, dann ist das nur eine andere Sichtweise, als die Anweisung inc(i) . Einmal steht das Objekt im Mittelpunkt, zum Anderen der Befehl (die Prozedur).

Delphi als nicht-OO zu bezeichnen ist imho abwegig. Delphi ist OO, weil es mir die Möglichkeit bietet, OOP zu betreiben. Ich kann es aber auch lassen, oder mischen. Und das es andere Sprachen gibt, die die Vererbungsgeschichte noch besser implementieren, steht ja ausser Frage, aber ist ein alter Käfer den kein Auto, nur weil es Lexus, BMWs und Ferraris gibt? Ist ein Kadett-Cabrio kein Auto, weil ich es auch als Blumenbeet verwenden kann?

Zur Abwechslung mal ein Zitat vom Wiki:

Zitat:

Objektorientierte Programmierung (Abkürzung OOP) ist ein Verfahren zur Strukturierung von Computerprogrammen, bei dem zusammengehörige Daten und die darauf arbeitende Programmlogik zu Einheiten zusammengefasst werden, den so genannten Objekten.

Zumindest konzeptionell arbeitet ein Programm dann nicht mehr (wie bei der prozeduralen Programmierung) so, dass sequenziell einzelne Funktionsbereiche eines Algorithmus durchlaufen werden, die dabei eine Anzahl Daten verändern, sondern die Programmlogik entfaltet sich in der Kommunikation und den internen Zustandsveränderungen der Objekte, aus denen das Programm aufgebaut ist.
...

Also, vom Konzept her arbeiten Objekte miteinander, von 'Nachrichten' steht da nix. Nur von Kommunikation. Merke: Auch ein Prozeduraufruf ist eine Form der Kommunikation.

Richtig lustig wird der Abschnitt, der einige objektorientierte Sprachen auflistet. Nicht das Wiki der Weisheit letzter Schluss ist, aber der Artikel dürfte einigen Schlaumeiern hier die Luft aus den Segeln nehmen.

Schönen Abend noch.

[Hansa]

Zitat von alzaimar:

Deswegen heisst es ja auch "Objekt Orientierte Programmierung" und nicht "Wenn Du auch nur eine Prozedur verwendest, wirst Du geteert und gefedert-Programmierung". Allerdings scheinen das noch nicht Alle begriffen zu haben.

Ne anscheinend immer noch nicht. 8)

Zitat von malo:

Übrigens solltest du bedenken, dass du grundsätzlich vorsichtig sein solltest mit Äußerungen wie "Delphi und Pascal ist eh fast das Selbe". Denn Delphi hat mit Pascal kaum noch was gemeinsam. Lediglich der Aufbau der Sprache und die grundlegenden Strukturen sind erhalten geblieben.
Aber alles was mit Units...Das war eine relativ primitive Sprache. Erst durch Borland wurde die Sprache attraktiv. Und Turbo Pascal <> Pascal! Da liegen auch noch Welten zwischen
Ab TP 5.5 wird die Sprache jedoch nicht mehr Pascal genannt, sondern i.d.R. Object Pascal, durch die Objektorientiertung.
Object Pascal kann man aber mit der Delphi-Language vergleichen. Aber Pascal ist eigentlich nicht vergleichbar mit Delphi...

Und noch einmal zum Mitschreiben: Delphi ist nicht objektorientiert. Sie hat höchstens objekteorientierte Spracheigenschaften. Objektorientiert ist sie aber nur, wenn man mit ihr nur OOP programmieren kann, und die prozeduale Programmierung nicht möglich ist.
Daher solltest du dir nochmal den Thread durchlesen

Malo, Sorry aber Du schreibst hier jetzt echt zuviel Unsinn. Wenn die Sprache selber und grundlegende Strukturen gleich sind, dann ist das auch für mich fast dasselbe. Daß diese "Sprache" mit der Zeit erweitert wurde, ist wohl nur natürlich.

Also nochmals Geschichte : in TP 4.0 wurden bereits Units eingeführt (uses usw.). In TP 5.0 waren auch noch relativ wichtige Neuerungen drin (glaube Speichermanagement geändert, zumindest Vorarbeiten für OOP), aber Borland hatte sich nicht getraut auch noch OOP selbst mit reinzupacken. Deshalb die einzige Zwischenversion TP 5.5 als erste weit verbreitete OOP- Sprache. Man denke auch an das zweite O !

Dann kam so was wie : "wer sendet die Nachricht ?" mit BP 6.0 Turbo Vision als völlig unbrauchbare Benutzeroberfläche. Win 3.11 war allerdings auch nicht besser. Die letzte DOS-Version war dann das stabile BP7 und dann erst kam Delphi. Ja ja, TP for Win vergißt man besser gleich.

Wers nicht glaubt, der soll im Borland Museum nachgucken und vor allem dort das Handbuch von TP 5.5 lesen. Eine der besten Einführungen in OOP.

[Horst_59]

Hallo,

Zitat von alzaimar:

Merke: Auch ein Prozeduraufruf ist eine Form der Kommunikation.

Mir ist nicht klar, wer bei einem Prozeduraufruf kommuniziert?
Objekte haben eine Identität und können entsprechend Nachrichten empfangen und senden.

Beispielhaft soll eine beliebige Liste als string ausgegeben werden.
Objektorientiert kann man sich vorstellen, dass alle Objekte in der Liste die Nachricht 'AsString' verarbeiten können (die Liste selbst auch).

Delphi-Quellcode:

5 AsString == '5';
'Test' AsString == 'Test';
ACar AsString == 'Opel Kadett';
with AList do begin
  Add(5);
  Add('Test');
  Add(ACar);
end;
AList AsString == '(''5''; ''Test''; ''Opel Kadett'')'

Prozedural sähe das ganze so ähnlich aus:

Delphi-Quellcode:

AsString(5) == '5';
AsString('Test') == 'Test';
AsString(ACar) == 'Opel Kadett';

AddNumberToList(AList,5);
AddStringToList(AList,'Test');
AddCarToList(AList,ACar);
AsString(AList) == '(''5''; ''Test''; ''Opel Kadett'')'

Der Unterschied ist der Zeitpunkt, zu dem bestimmt werden kann, welcher Code ausgeführt wird, um den String zu erzeugen. Prozedural geschieht dies mit Hilfe früher Bindung, also zur Compilezeit. Das heisst, es muss eine Prozedur für jeden Variablentyp existieren, der in einen String umgewandelt werden kann. In
AsString(AList) würde über die Liste iteriert, geprüft werden, was für ein Element drin ist und die richtige Prozedur aufgerufen. Wenn plötzlich auch Flugzeuge als String ausgegeben werden sollen, dann muss
AsString(APlane) implementiert werden, und die Prozedur zur Ausgabe der Liste angepasst werden.

Objektorientiert würde der Empfänger der Nachricht (APlane) entscheiden was zu tun ist. Alle anderen können sich darauf verlassen, dass das Objekt sich selbst am besten damit auskennt, was es selbst zu tun hat und müssen lediglich die Nachricht AsString kommunizieren. Erst zur Laufzeit wird durch den Empfänger der Nachricht bestimmt, was konkret geschieht.

Freilich kann dies auch mit Delphi so implemetiert werden, allerdings nicht prozedural, sondern objektorientiert. Hat ja niemand gesagt, dass das nicht unterstützt wird.

Gruß
Sebastian