Hi zusammen,

ich hab mal eine etwas andere bzw. ausergewöhnliche frage...

Und zwar muss ich ein Referat halten und muss daher wissen warum Delphi eine Objektorientierte Programmiersprache ist.
Ich bräuchte dazu eine sehr sehr ausführlich antwort.

Ich bin natürlich über jede Antwort sehr froh!!

Danke
Blacked

Nun, weil die Entwicklungsumgebung eben auf der OOP fußt.

Man muss ja nun nicht unbedingt OOP in Delphi anwenden, kleine Konsolenapps sind sicherlich auch "traditionell" machbar, aber sobald man ein Delphi-Formular oder einen Button benutzt, wendet man OOP an. Sämtliche Komponenten in der Komponentenpalette sind eben Objekte.

Willst du eher eine Definition von OOP?

Cu,
Udontknow

HI,

also OOP heiß, das man sogenannte Klassen zur Verfügung hat auf die man zugreifen kann. Die Klassen sind wie Schablonen zu sehen mit der man immer wieder das gleiche erzeugen kann z.B. Button1,2,3,4,n. Auf die Klassen greift man mit Objekten zu die man, damals immer meines Wissens, und heute teilweise selber erstellen muss. Z.B. ein Button den du auf einem Formular siehts ist aus einer Klasse erzeugt nämlich TButton. TButton ist also die Klasse und um einen Button zu erstellen musst du ein OBJEKT der KLASSE TButton erstellen. Alle Eigenschaften des Objekts/Buttons werden von der Klasse zur Verfügung gestellt. Da das Formmular später aus lauter Objekten besteht (das Formular selbst ist auch eins) nennt sich das ganze Objekt Orientierte Programmiersprache.

(ich hoffe das war einigermaßen verständlich )

Hallo,

Delphi ist, im gegensatz zu z.B. JAVA, nicht vollständig Objekt-Orientiert. Das währe der Fall wen jede Funktion zu einem Objekt gehötre. Das ist in Delhi-Language absolut nicht der Fall. Wie Udontknow richtig feststellte, ist es sogar möglich Konsolenanwendungen komplett ohne Objekte zu Schreiben.
Allerdings bietet Delphi die möglichkeit Objekte zu erzeugen dabei werden auch verschiedene zugriffsbegränzungen geboten (private, protectet, public & publisched) was z.B. bei PHP nicht der Fall ist. Vererbung ist auch vorhanden. Was nicht möglich ist, ist mehrfachvererbung, da dies wohl ein ziemlich Problematisches Prinzieb ist. Über Interface deklarationen lassen sich aber einige aspeckte der Mehrfachvererbung nachahmen.
Welche dieser eigenschaften jetzt im einzelnen gelten müssen damit sich eine Sprache-Objekt Orientiert nennen darf weiß ich nicht. Ich schätze das reine Objekte (also zusammfassen von Funktionen und Daten) inklusive Vererbung dazu ausreichen.

Ansonsten solltest du in dem Text genug Stichworte finden nach denen du das Internet durchsuchen kannst .

Gruß
Klabautermann

Vielen Dank an @lle...

Das hilft mir schon sehr sehr sehr sehr weiter!

Wenn noch jemand was zu ergänzen hat, nur her damit!!!

Aber das hat mir wirklich schon viel geholfen.

Danke nochmal.

Also Objekte haben einige große Vorteile:
1. Die Methoden und die Daten sind gekapselt.
d.h. Ein Objekt hat nicht nur Eingenschaften, sondern auch Methoden diese Eigenschaften zu manipulieren. Das macht die Sache deutlich übersichtlicher.

2. Ein Programmierer kann die Objekte verwenden, ohne genau zu wissen wie sie funktionieren. Dadurch ist eine verteilte Arbeit möglich. (OK das geht auch ohne Objekte bereits mit Units)

3. Objekte erben.
So ist es sehr leicht zB ein Edit-Feld zu machen, das zB nur Zahlen als Eingabe zulässt. Man muß nur wenig über das Editfeld selber wissen. Man beerbt ein normales Edit und (über)schreibt nur den Teil, den man anderst haben will und muß sich um den Rest keine Gedanken machen.

...

Klabautermann hat folgendes geschrieben:

Delphi ist, im gegensatz zu z.B. JAVA, nicht vollständig Objekt-Orientiert. Das währe der Fall wen jede Funktion zu einem Objekt gehötre. Das ist in Delhi-Language absolut nicht der Fall. /*cut*/

Warum? Solange Du keine Konsolenanwendung erstellst (obwohl ich nicht weiß, ob das da nicht auch der Fall ist), gehört JEDE Funktion, Prozedur, Variable.... zu einem Objekt, denn was ist denn sonst TForm1 ? Ein Objekt aus der Klasse TForm. Und wird z.B. die FormCreate-Proz. erstellt? Als Prozedur des Objekts TForm1. Und wie ruft man die von außerhalb auf? Form1.FormCreate(...).
Was ist daran also nicht objektorientiert (mann oh mann, ein schwieriges Wort, wenn mans schreibt.... ) ?
Und bei der Konsolenanwendung haben wir ja auch das Programm selbst.....
OK, darüber lässt sich jetzt vielleicht streiten, aber bei dem oben denke ich, dass ich recht habe. Korrigiert mich andernfalls (aber nur mit guter Argumentation ).

Gruß

Hallo,

UGrohne hat folgendes geschrieben:

Warum? Solange Du keine Konsolenanwendung erstellst (obwohl ich nicht weiß, ob das da nicht auch der Fall ist), gehört JEDE Funktion, Prozedur, Variable.... zu einem Objekt, denn was ist denn sonst TForm1 ?

wozu gehört IntToStr? Oder AssignFile?
Vollständig-Objektorientiert währe Delhi wenn es nicht möglich währe irgendeine Funktion ohne Objekt zu erstellen. Du kannst aber jederzeit eine neue Unit anlegen und da deine Prozeduren und funktionen völlig Objektfrei ablegen.

Gruß
Klabautermann

Und die nächste Runde... Ich glaube, hier entbrennt jetzt eine heftige Diskussion.

Gute Argumentation, aber wir können die Unit auch als Container für andere Objekte ansehen und man macht ja auch dasselbe, wie mit den Klassen, wenn man sie benutzen will: Man definiert sie in der uses-Klausel. Und der Aufruf geht wieder über IrgendeineUnit.IrgendeineProz

Ich denke, damit kann man auch eine Unit als Objekt auffassen....

So und jetzt sind Deine Beispiele auch wieder im System, denn inttostr gehört in SysUtils und assignfile in system

Versuch mal SysUtils.InttoStr(i); ....

*hehe*

Achja, und dann wären wir ja wieder bei einer Konsolenapp. -> Kann man die nicht auch als Unit sehen, einen Container für Objekte?

Diskussionsfreudigen Gruß

P.S.: Freu mich schon auf die nächste Runde

Hallo,

wie du gesagt hast, sind Units Kontainer für Objekte, Methoden, Variablen, Typen, Constanten und was auch immer ich vergessen habe. Sie sind aber keine Objekte, denn ich kann sie nicht beerben.
Ein Punkt macht noch keine Klasse. Sonst währen Records auch welche.

Hier übrigens noch ein kleiner Auszug aus Crazy Java User Group:

Crazy Java User Group hat folgendes geschrieben:

JAVA ist vom Sprachkonzept her vollständig objektorientiert. Bis auf die primitiven Datentypen wie Integerzahlen, ... gibt es keine Elemente, die nicht von der Klasse Object abgeleitet sind. Auch gibt es im JAVA-Sprachkonzept keine Möglichkeit abstrakte Funktionen standalone zu definieren, wie z.B. INT(), welche einen Ganzzahlwert zurückgibt. Auch Strings (Zeichenketten) und Datumsdatentypen sind bereits Objekte und damit Ableitungen der Klasse Object.

und noch ein Text den ich bei der UNI-Hannover gefunden habe, welcher für Blacked interessant sein könnte:

UNI-Hannover hat folgendes geschrieben:

Objektorientiert Java ist vollständig objektorientiert aufgebaut. Im Gegensatz zu der prozeduralen Programmierung, in der man zwischen Daten und Prozeduren unterscheidet, existieren bei der Objektorientierung nur Objekte, die als eigenständige Einheiten interpretiert werden können. Man versucht, die Objekte der realen Welt abzubilden. Die Grundelemente einer objektorientierten Sprache sind Kapselung und Vererbung. Kapselung bedeutet, daß der Zustand eines Objekts nur über definierte Methoden veränderbar ist. Die Daten sind also in den Objekten gekapselt. Vererbung heißt, daß Objekte Eigenschaften und Methoden von anderen Objekten übernehmen können. Manche objektorientierten Programmiersprachen bieten die Möglichkeit sogenannter Mehrfachvererbung, d. h. ein Objekt kann Eigenschaften und Methoden von mehreren Objekten erben. Dies kann in manchen Fällen zu Konflikten führen. Java verzichtet auf die Mehrfachvererbung und bietet statt dessen die Implementierung sogenannter Interfaces.

Gruß
Klabautermann

OK, Du hast mich erwischt, in dem Punkt muss ich Dir also wohl zustimmen

Aber es gibt noch ein anderes Argument gegen Units als Objekte:
Man braucht keinen SPeicher für Sie zu reservieren, man muss sie also nicht erzeugen (Create). Das ist mir aber erst nach dem Posten aufgefallen.

Trotzdem bleibt Delphi für mich OOP, so. *g*

Gruß

Hallo,

UGrohne hat folgendes geschrieben:

Trotzdem bleibt Delphi für mich OOP, so. *g*

natürlich ist Delphi-Language eine Objekt-Orientierte Programmiersprache, nur eben keine vollständig Objekt Orientierte.

Gruß
Klabautermann

OKOK, ich glaube, jetzt wirds zu detailliert.

Ich finde wir sollten im Interesse aller, diese Diskussion jetzt und hier beenden, sonst gehen uns gegenseitig noch irgendwann an die Gurgel