Delphi objektorientiert?

[choose]

Hi Chewie,

Programmiersprachen(konzepte) sind als Abstraktion von im speicherbefindlichen Anweisungen für eine CPU zu verstehen. Assembler abstrahiert von diese Maschinensprache, wie Assembpler mit Preoprozessoren von der konkreten Umsetzung wiederkehrender Idiome abstrahieren. Prezedurale Programmierung beschreibt die Abstraktion und Zerlegung von ausführbarem Programmcode, letztlich der Maschinensprache. Die Objektorientierung hingegen fasst Daten und Code als logische Einheiten zusammen.
Konstrukte wie Schleifen oder FAllunterscheidungen sind in puren, objektorientierten Sprachen überflüssig, weil von ihnen abstrahiert wird.

Code:

block := [:each | each print].
sequence := 1 to: 5.
sequence do: block.

bzw

Code:

1 to: 5 do: [:each | each print].

Dass sie letztlich in der Regel von einer iterativen Maschine abgearbeitet werden muss, ist mir klar.

[Chewie]

@Choose:

Nach deinen Ausführungen gibt es dann keine objektorientierten und prozeduralen Sprachen, sondern leidiglich Konzepte dieser Art und Sprachen, die diese Konzepte aufgreifen und implementieren.

Das Konzept der objektorientierten Programmierung und das der prozeduralen ist grundverschieden. Objektorientierte Sprachen bauen aber auf prozeduralen auf, stellen also eine Spezialisierung dieser Sprachen dar.

[choose]

Hey Chewie,

Zitat:

Zitat von Chewie

Nach deinen Ausführungen gibt es dann keine objektorientierten und prozeduralen Sprachen, sondern leidiglich Konzepte dieser Art und Sprachen, die diese Konzepte aufgreifen und implementieren.

Die Konzepte sind da und so auch die Sprachen. Es gibt durchaus Sprachen, die Code nicht von Daten trennen, sondern alles(!) als Objektbetrachten. Der Code selbst ist dabei genauso ein Objekt wie der "Stack" oder Kontext des Ausführungsstrangs. Ausführungsstränge sind Objekte von Klassen, die selbst Objekte von Metaklassen sind, die Objekte sind...

Zitat:

Zitat von Chewie

Objektorientierte Sprachen bauen aber auf prozeduralen auf, stellen also eine Spezialisierung dieser Sprachen dar.

Nein. Sprachen, die keine prozeduralen, syntaktischen Elemente aufweisen und direkt in eine ausführbare Form übersetzt werden, haben keinen Zusammenhang mit prozeduralen Sprachen.

[Chewie]

Choose, kannst du mir mal ein beispiel für eine Objektorientierte Sprache geben, die keine prozeduralen Elemente enthält? Ich kann mir nämlich nicht vorstellen, wie das aussieht.

[choose]

Hey Chewie,

nimm mein Beispiel von oben (#21) es zeigt eine "Schleife", die die "Zahlen" 1 bis 5 ausgibt.
block ist ein Objekt, dass die Nachricht value: aValue empfangen kann. Es ist über den Konstruktor

Code:

[:each | each print]

so angelegt, dass es bei der Varbeitung der Nachricht dem Parameter aValue die Nachricht print schickt. Gültig ist daher der Code

Code:

block value: self

bei dem das Objekt self letzlich die Nachricht print gesendet wird.
Mit der Nachricht to: aNumber erzeugt ein Zahlenobjekt eine Sequenz mit den Intervallgrenzen des eigenen und dem übergebenen Wert. Diese Sequenz ist ein OBjekt eines Nachfolgers von Collection, einer Klasse, deren Exemplare die Nachricht do: aBlock verstehen. Wann immer eine Collection diese Nachricht abarbeitet, wird aBlock nacheinander jedes Element der Collection mit value: aValue übergeben.
Also

Code:

aBlock := [:i | i print].
aNumber := 1;
anotherNumber := 5;
aSequence := aNumber to: anotherNumber;
aCollection := aSequence;
aCollection do: aBlock;

bzw

Code:

(aNumber to: anotherNumber) do: aBlock

oder

Code:

1 to: 5 do [:i| i print]

dieses Beispiel orientiert sich an der Sprache Smalltalk.

[mschaefer]

Moin zusammen,

Zitat:

Zitat von Chewie

Choose, kannst du mir mal ein beispiel für eine Objektorientierte Sprache geben, die keine prozeduralen Elemente enthält? Ich kann mir nämlich nicht vorstellen, wie das aussieht.

Tja dass wird er wohl kaum können, der Versuch hat allerdings durchaus Niveau!

Also fangen wir doch mal klein an:

1.
Am Anfang wurde alles in eine Routine gehakt, ohne Procedure und Funktionen, findet man heute noch bei SimpleControllern.

2.
Verdammt schnell erkannte man, dass dies irgendwie unübersichtlich war seine Assemblerbefehle so hintereinander zu setzen und es wurde das Procedurale-Konzept mit Funktionen und Proceduren und der Variablenübergabe eingeführt. Funktionierte prima auf dem ZX80, Commodore und dem guten alten Apple und findet sich auch heute noch bei der Mikrocontrollerprogrammierung.

3.
Irgendwann wurden die Zugehörigkeit der Proceduren und Funktionen ein größeres Problem und man führte verschieden Programmkompartimente ein, wie Units unter Pascal und Module unter Basic, wo man themenzusammenhängende Routinen ablegte.

4.
Nicht nur die Themenzugehörigkeit einer Routine gewinnt an Bedeutunt, sondern auch zu welcher Anwendungsaufgabe diese gehört. Es kam zur Einführung der Objekte, die sich spezialisiert um Aufgabenbereiche kümmerten. Diese Objekte verwenden natürlich auch das Proceduralkonzept mit Variablenübergabe weiter können aber aufgrund der Zugehörogkeit zum Objekt für den Zugriff von Aussen gesperrt werden. Das Objekt gibt nur Anwendungsaufgabenrelevantes für die Umwelt an.
Nicht nur PC´s sondern auch die neuen Mikrocontroller haben inzwischen objectorientierte-procedrual organisierte Sprachen.

Fazit: Objectorientiert geht ohne Procedural nicht.

PS:
" i print " ist oben die Procedure, der Parameter steht halt vor dem Befehl.
Das ist trivial die polnische Notation, die durchaus viel Schreibarbeit sparen kann.

PPS: I
Denke wir sprechen hier eigentlich noch über etwas anderes: Es gibt Sprachen, die objectungebundene Proceduren nicht zulassen.
Man sorgt dafür, dass sich der Entwickler von vorneherein Gedanken über die Aufgabenzugehörigkeit seiner Rountienen macht.
Meine, dass Smalltalk in diese Kategorie gehört. Sicher ist aber Modulo da zu sehen.

Insofern würde das Beispiel von Choose gut passen und mich würde es nicht wundern, wenn dies Objectungebundenheit irgendwann einfach ohne es groß zu bemerken Verschwindet. Früher gab es in Delphi nur eine System-Unit, heute gibt es ein System-Object.


Viele Grüße // Martin


3PS: "c vs k" ist der alte lateinische Streitpunkt...

[choose]

Zitat:

Zitat von mschaefer

Zitat:

Zitat von Chewie

kannst du mir mal ein beispiel für eine Objektorientierte Sprache geben, die keine prozeduralen Elemente enthält?

Tja dass wird er wohl kaum können

Dreh- und Angelpunkt Deiner Darstellung, mschaefer, ist die historische Betrachtung der Entwicklung. Mir wird Deine Folgerung leider nicht ganz klar, glaube aber zu erkennen, dass Du die Möglichkeit, Befehle gruppieren zu können, als Prozedural ansiehst und glaubst, dass Objektorientierung ähnlich realisiert werden muss. Ich gehe weiterhin davon aus, dass Du bisher nicht mit Sprachen wir Smalltalk gearbeitet hast und daher hybrid-Sprachen wie Java oder C++ zum Vergleich heranziehst.

Aus meiner Sicht könnte diese Aussage mit der folgenden verglichen werden: "Jedes Flugzeug ist auch ein Auto". Historisch gesehen basieren beide (meistens) auf Motoren, die zuerst in Automobilen eingesetzt wurden. Außerdem besitzen Flugzeuge (meistens) auch Reifen, die denen eines Automobils nicht unähnlich sind.
Mit Sicherheit gibt es noch weitere Ähnlichkeiten zwischen Flugzeugen und Automobilen, der wesentliche Aspekt eines Flugzeugs ist jedoch die Fortbewegung in der Luft (die ein Automobil nur kurzzeitig zulässt) und nur zur Zweckerfüllung, dem Transport von Masse, ist es überhaupt notwendig, das solche Flugzeuge auf einer staßenähnlichen Fahrbahn landen oder starten.

Zur Objektorientierung: Keineswegs ist i print lediglich eine spezielle Notation zur Vereinfachung. Auch sind dies keine typgebundenen Prozeduren, die in unterschiedlichen, überladenen Varianten zur Übersetzungszeit gewählt werden. Das Beispiel zeigt, wie einem beliebigen "Objekt" die Nachricht "print" gesendet wird. Dazu muss zur Übersetzungszeit weder bekannt sein, ob i diese Nachricht versteht noch muss "print" überhaupt implementiert sein.
Weil Methoden wie Klassen gleichfalls Objekte sind, können sie zusammen zur Laufzeit dynamisch erzeugt und an spezielle Klassen/Objekte gebunden werden. Sollte i im Beispiel die Nachricht trotzdem nicht in Form einer vorliegenden Implementierung beantworten können, so wird in Smalltalk die Nachricht MessageNotUnderstood gesendet, was schlussendlich vergleichbar mit einer Exception ist. Der Clou jedoch: Weil auch Nachrichten selbst Objekte sind, kann die Implementierung von MessageNotUnderstood so angepasst werden, dass aus den Daten der ursprünglichen Nachricht etwas sinnvolles abgeleitet wird. So ist es in Smalltalk relativ einfach möglich, einen generischen Proxy zu implementieren, der Nachrichten, die er selbst nicht beantworten kann, delegiert und Antworten, wieder verpackt, an den Klienten sendet. Das alles geschieht vollkommen transparent und mit Nachrichten, die zur Übersetzungszeit des Proxies gänzlich unbekannt waren...

[alzaimar]

Zitat:

Zitat von mschaefer

3PS: "c vs k" ist der alte lateinische Streitpunkt...

Nee, ist eindeutig im Duden definiert.

[Hansa]

Die Hauptfrage ist ja wohl geklärt. Aber mich stört an der Diskussion, daß sie erstens viel zu theoretisch ist, prozedural besser und blabla. :mrgreen: Das Wichtigste an OOP ist nicht mal erwähnt worden : das ist die Vererbung. Und die Möglichkeit einen Typ zu deklarieren, der gleich die zugehörigen Methoden hat, um die Daten zu bearbeiten wurde auch nur am Rande erwähnt. Ob das ganze sich hier und da nun Object, Class oder sonstwie nennt ist egal. Auch eine Procedure ist nicht mehr prozedural im klassischen Sinne, sofern am Ende der Deklaration so was wie virtual, override usw. steht. Das ist dann OOP. Wo das nun anfängt und aufhört ist mir egal. Ich baue mir schon seit TP 5.5 meine Grundgerüste und erweitere sie OOP-mäßig so, wie es sinnvoll ist. Es kommt immer auf die Dosierung an. Soll aus einem Nettobetrag ein Bruttobetrag werden, so schreibe ich dafür eine Funktion und im Programm steht SummeBrutto := brutto (SummeNetto); Wer für sowas mit Objekten rumfuchtelt, der programmiert IMHO ohne Sinn und Verstand. 8)

[alzaimar]

Zitat:

Zitat von Hansa

...Wer für sowas mit Objekten rumfuchtelt, der programmiert IMHO ohne Sinn und Verstand. 8)

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.