Delphi objektorientiert?

[Rapthor]

Hallo,

ich habe mal eine grundsätzliche Frage. Seit wann ist Pascal objektorientiert?
Denn ich dachte bis jetzt, dass es sich um eine rein prozedurale Programmiersprache handelt. Ich habe vor einiger Zeit mit Turbo Pascal und dann mit Delphi programmiert. Als ich dann mit JAVA, C# usw. begann, fielen mir sofort die Unterschiede zu Delphi auf und ich hörte eben auch, dass Pascal prozedural sei.

Ist dies seit Object-Pascal vorbei und ist Delphi .NET eigentlich objektorientiert? Desweiteren frage ich mich, ob mit der Objektorientierung nicht jede Menge Dinge neu konzeptioniert werden mussten, im Gegensatz zur Benutzung prozeduraler Sprachen?!

Ich hoffe, ihr könnt mir ein wenig weiterhelfen.

[Ultimator]

Soweit ich weiß, kann man seit TurboPascal 5.5objektorientiert programmieren.
Und Object-Pascal ist die Sprache "Delphi", ist nur ein anderer Name ;)

Delphi ist natürlich objektorientiert, genau wie Delphi.NET.
Delphi.NET schon allein deswegen, weil das .NET-Framework eigentlich komplett objektorientiert ist.
Delphi.NET ist von der Logik, die dahintersteckt eigentlich genau das gleiche wie C# ;)

[glkgereon]

Naja, also soweit ist ne Prozedurale Sprache ja auch nicht von einer Objektorientierten weg...


Zu ObjectPascal.
Wie der Name schon sagt heisst es so, seit "Object" eingeführt wurde, der Vorläufer einer Klasse.
Von daher würde ich sagen:
Ja, ObjectPascal war schon "immer" objectorientiert.
Nein, das Ur-Pascal von Wirth war/ist nicht objektorientiert.
TurboPascal als "IDE" wurde glaub ich erst mit der Entwicklung von ObjectPascal auf den Markt geworfen (Stimmt das?) und ist damit auch "schon immer" objektorientiert.
Edit: OK, stimmt wohl nicht :)

Allerdings gab es Unterschiede zwischen object und class...die weiss ich aber nicht auswendig :)

Delphi ist es in jedem Fall.

.Net kenne ich nicht...

[Robert_G]

Schaue dir mal eine normale Formulardatei an. Was fällt dir an der Deklaration auf? ;)

btw: Delphi ist halb objektorientiert, halb prozedural. Es ist auch ein ziemlicher PITA darin rein OO zu programmieren. Aber den Namen Object-Pascal hat es schon aus gutem Grund getragen. ;)
(Nennt sich ja seit D7/D6 nur noch ... Delphi)

[malo]

Zitat:

Zitat von Robert_G

(Nennt sich ja seit D7/D6 nur noch ... Delphi)

Eigentlich heißt sie ja "Delphi-Language", läuft aber aufs Gleiche hinaus :zwinker:

Vielleicht ist auch der Wikipedia-Artikel interessant ;)

[Der_Unwissende]

Hi,
das Problem ist, dass es viele Sprachen vor dem großen run auf die OOP gab. Und Objekt Orientierung gibt es halt auch schon ein ganzes Weilchen länger als viele glauben.
Jedenfalls kannst du in Delphi (ähnlich wie in C++) sowohl prozedural als auch Objekt Orientiert arbeiten. Aber streng genommen ist es damit natürlich keine reine Objekt Orientierte Sprache. Selbes gilt aber auch für Java. Hier geht die Objekt Orientierung zwar deutlich weiter, aber primitive Datentypen sind kein Objekt (z.B. byte, int, float, double, ....). Auch Enumerations sind es denke ich nicht.
Wenn du also Java mit z.B. SmallTalk vergleichst, dann wirst du auch Java als nicht streng OO einstufen können (aber man müsste schon eher kleinlich sein :-D)

Gruß Der Unwissende

[Chewie]

Außerdem ist objektorientierte Programmierung nur eine spezielle Form der prozeduralen Programmierung.

Man kann auch mit C objektorientiert programmieren. Nur muss man halt Dinge, die beispielsweise bei C++ der Compiler übernimmt, selbst erledigen. Das Konzept ist aber das gleiche.

[schöni]

Hallo!

Es ist sicher, das seit Turbo-Pascal 5.5 objektorientiertes Programmieren möglich ist. Unfangreiche Objektbibliotheken, von Beispielen abgesehen werden seit Turbo-Pascal 6.0 mitgeleifert. Bis Turbo-
Pascal7.0 waren die Objekte binär anders aufgebaut, als die heutigen Klassen, was auch im Typ Object
zum Ausdruck kam.

Delphi-Quellcode:

type
 TTP5bis7Object = object
   Datenfeld1: Typ;
   .....
   DatenfeldN: Typ;
   Methode1;
   ....
   MethodeN(parameter:Typ[;parameter:Typ...]);
 end;

Es gab keine Properties

Delphi-Quellcode:

type
 TDelphiObject = class   //seit Delphi 1.0
 end;

Wie heute altbekannt!

Die Objekte im alten Stil versteht Delphi aber immer noch und hat sie sogar soweit erweitert,das man
ebenso alle bekannten Schutzklassen und auch Properties dabei wie bei den Klassen verwenden kann. Ist trotzdem nur für Kompatibilitätszwecke gedacht, zumal die VCL im Klassenmodell erstellt ist.

Schöni

[Rapthor]

Sehr interessant! Danke, dann weiß ich es ab heute besser.

[3_of_8]

Eine Klasse ist außerdem ein Pointer auf ein object, ich denke, das ist der Unterschied. Wenn ich nicht recht habe, dürft ihr mich jetzt hauen. (virtuell)

[Robert_G]

Zitat:

Zitat von 3_of_8

Eine Klasse ist außerdem ein Pointer auf ein object, ich denke, das ist der Unterschied. Wenn ich nicht recht habe, dürft ihr mich jetzt hauen. (virtuell)

Gerne doch! :)
*dresch* *poff*

[3_of_8]

Hat Dax gestern geschrieben:

Zitat:

object = Record mit Methoden
class = Pointer auf Record mit Methoden
^class = PPointer...

[Robert_G]

Zitat:

Zitat von 3_of_8

Hat Dax gestern geschrieben:

Zitat:

object = Record mit Methoden
class = Pointer auf Record mit Methoden
^class = PPointer...

Och menno...
Kiek mal hier.

[3_of_8]

Ich habe das Gefühl, ein Objekt ist für jeden etwas anderes. *g*

[negaH]

Wenn ich mich richtig erinnere war PASCAL sogar die erste Programmiersprache überhaupt in der man OOP ausprobierte. Zu dieser Zeit gab es kein JAVA, kein .NET, kein Modulo kein SmallTalk etc.pp. Die zweite Sprache die dann OOP enthielt müsste ADA gewesen sein, wird ja auch im Militär benutzt. Kann mich aber auch täuschen ;)

Wer also behauptet PASCAL sei rein prozedural um zu beweisen das seine bevorzugte Sprache OOP sei, der macht zwei Fehler:
1.) er vergisst die Geschichte
2.) er bemerkt nicht das reinste OOP überhaupt nichts bringt. Die prozedurale Programmierung gehört wie die OOP gleichermaßen zu den nötigen Mitteln um einen Zweck zu ereichen.

Gruß Hagen

[Sidorion]

Also das mit Objekt verhält sich so:
Eine "Klasse" (Type TMyObj=Class...) ist eine Schablone/Vorlage für alle Objekte dieses Typs. Der Compiler legt für jede Klasse ein Stück Code an, in dem die Prozeduren/Funktionen stehen (Code-Segment). - grob gesprochen, da spielen Vererbung usw noch rein, was aber hier die Sache unnötig verkompliziert -
Eine "Instanz" (Var MyObj: TMyObj) ist ein konkretes Objekt, für dessen Member jeweils ein Stück im Speicher reserviert wird (Datensegment).
Wenn man jetzt eine Methode der Instanz ruft (MyObj.Print), wird der Code der Klasse abgearbeitet, aber der Datenteil dieser Instanz verwendet. Bei Aufruf der selben Methode einer anderen Instanz (My2ndObj.Print) wird das SELBE Stück Code abgearbeitet, allerdings mit einem anderen Datenteil, nämlich den von My2ndObj.
Die Verwendung des Begriffes "Objekt" ist also unsauber und beinhaltet eigentlich beides (Bei Objektorientierung verwendet man ja Klassen und Instanzen). Besser ist, von Klassen und Instanzen zu sprechen.

[Khabarakh]

Zitat:

Zitat von negaH

Wenn ich mich richtig erinnere war PASCAL sogar die erste Programmiersprache überhaupt in der man OOP ausprobierte. Zu dieser Zeit gab es kein JAVA, kein .NET, kein Modulo kein SmallTalk etc.pp. Die zweite Sprache die dann OOP enthielt müsste ADA gewesen sein, wird ja auch im Militär benutzt. Kann mich aber auch täuschen ;)

Laut dieser Grafik liegt Pascal höchstens im zeitlichen Mittelfeld :wink: .

[choose]

Hi Hagen :)

Zitat:

Zitat von negaH

Wer also behauptet PASCAL sei rein prozedural [..] der bemerkt nicht, das reinste OOP überhaupt nichts bringt. Die prozedurale Programmierung gehört wie die OOP gleichermaßen zu den nötigen Mitteln um einen Zweck zu ereichen.

Mir wird nicht ganz klar, was Du meinst. Stellst Du fest, dass OOP allein sinnlos ist und letztlich immer eine "Prozedur" notwendig ist, um ein sinnvolles Programm zu gestalten? Was ist mit Sprachen wie Smalltalk? Und (seiten-)effektfreien (zB funktionalen) Sprachen?

[Chewie]

Gibt es denn objektorientierte Sprachen, die nicht prozedural sind?
In der Theorie tauschen Objekte Nachrichten aus, in der Praxis werden aber Prozeduren (die eben Methoden heißen) aufgerufen.
Vorausgesetzt, eine andere Art der Implementierung gibt es nicht, sind objektorientierte Sprachen prozedural.

[Tubos]

Ich glaube Hagen meinte dass es nicht notwendig ist eine 100%ig objektorientierte Sprache zu haben, um sauber OOP machen zu können. In Java sind ja die primitiven Datentypen keine Klassen.

Ganz abgesehen davon bin ich der Meinung dass es auch heutzutage kein Problem ist, mit prozeduraler Programmierung saubere Anwendungen zu schreiben.
Beispielsweise in PHP: Die Webseite meiner Band, die recht umfangreiche Funktionen für die Mitglieder bietet, ist rein prozedural programmiert. Natürlich war das kein riesiges Projekt, aber ich bin ohne OOP problemlos zurechtgekommen.

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

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

Zitat von Nils_13

Delphi ist Objektorientiert.

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

Zitat:

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:

Zitat von malo

Zitat:

Zitat von Nils_13

Delphi ist Objektorientiert.

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

Zitat:

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:

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 ? :shock: 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. :mrgreen: Die erste könnte ich (relativ) leicht verschmerzen, das zweite aber nicht !

[Horst_59]

Servus,

eine sehr interessante Diskussion, die hier aufgekommen ist.

Zitat:

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:

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

Delphi-Quellcode:

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:

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:

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. :mrgreen: 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 :lol: 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:

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

Delphi-Quellcode:

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

Delphi-Quellcode:

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