Was ist ein Objekt ?

[mkinzler]

Nein es geht um den Unterschied von

Delphi-Quellcode:

TObj = Object
    ...
end;

und

Delphi-Quellcode:

TCl = Class
    ...
end;

[mr_emre_d]

Appol.:
Das mit Create geht nicht !

Hier ein Codebsp:

Code:

  TBlubObject = object
    Blub: String[50];
    constructor Create;
    procedure ShowBlub;
  end;
.
.
.

implementation

procedure TForm1.FormCreate(Sender: TObject);
var
  Blub1, Blub2: TBlubObject;
begin
  Blub1 := TBlubObject.Create;  // --> das geht nicht! 
  Blub1.ShowBlub;

  Blub2.Blub := 'Das ist Blub2';
  Blub2.ShowBlub;
end;

constructor TBlubObject.Create;
begin
  Blub := 'Schwachsinn';
end;

procedure TBlubObject.ShowBlub;
begin
  ShowMessage( Blub );
end;

[littleDave]

Soweit ich mich an Objects erinnern kann, musst du die nicht extra erstellen.

Delphi-Quellcode:

type
  TBlubObject = object 
    Blub: String[50]; 
    procedure Initiate;
    procedure ShowBlub; 
  end;

procedure TForm1.ButtonClick(Sender: TObject)
var Blub: TBlubObject;
begin
  Blub.ShowBlub;  // Leerstring ausgeben
  Blub.Initiate;  // "Blub.Blub := 'irgendwas'
  Blub.ShowBlub;  // 'irgendwas' ausgeben
end;

procedure TBlubObject.Initiate;
begin
  Blub := 'irgendwas';
end;

procedure TBlubObject.ShowBlub;
begin
  ShowMessage(Blub);
end;

Alle Angaben ohne Gewähr, da Delphi nicht offen

[mkinzler]

Es gab damals keine Konstruktoren/Destruktoren

[teebee]

Zitat von mkinzler:

Es gab damals keine Konstruktoren/Destruktoren

Wann ist damals? In TP5.5 gab es die schon. Und vorher gab es keine Objekte in TP.

[mkinzler]

In meiner erinnerung gab Methoden aber keine Konstruktoren

[Apollonius]

Ohne unhöflich erscheinen zu wollen: Ihr könnt doch lesen, oder? In Beitrag 6 habe ich ein funktionsfähiges Beispiel mitsamt Konstruktor gepostet.

[negaH]

Worin liegt der primäre Unterschied zwischen einem Ottomotor und einer Gasturbine ? Das eine ist die Weiterentwicklung des Anderen. Und Gleiches trifft auf Objekte und Klassen zu, wobei schon die Namensgebung im Grunde falsch ist.

Klassen sind mit Objekten garnicht vergleichbar da eine Klasse eher wie ein Template die allozierbaren Objekte = Instanzen umschreiben. Wir erzuegen aus einer Klasse, also einem OOP Typ, durch Allozierung im Heap oder meinetwegen auch Stack, eine Instanz. Diese Instanz bezeichnet man auch als ein Objekt.

Eine Klasse ist also eine Datentyp-Deklaration die das Verhalten und Aussehen ihrer zur Laiufzeit erstellbaren Instanzen = Objekte definiert.

Evolutionär betrachtet waren die Delphi, eg. Borland Pascal 5, Objekte nur die Vorstufe zu Klassen. Später wurden die "Klassen" als solches eingeführt aber im Grunde könnten die alten Delphi Objekte alles das unterstützen was heutige Klassen können. Eine Klasse in Delphi unterscheidet sich auf 3 Arten von Objekten in Delphi

1.) die Art und Weise wie deren Klasse im Codesegment gespeichert wird. Eine Klasse ist ein Record im Codesegement indem per RTTI=Run Time Type Information alles was diese Klasse kann gespeichert wurde. Also die virtuellen und dynamischen Methoden in der VMT und DMT, alle publisched Eigenschaften und Ereignismethoden samt Paramater dieser Methoden, alle implementierten Intaerfaces usw. usw.
Die alten Objekte in Delphi stellen eine Untermenge dieser Klassenstruktur dar, das erkennt man auch sehr einfach im Aufbau dieses Klasenrecords. Der Klassenzeiger, also TObject.ClassType^ = PPonter(Self)^^ zeigt mitten in diesen Klassenrecord im Codesegment exakt an den Begin der VMT=Virtual Method Table. Nun die alten Objekte und deren Klassenrecord begint exakt mit einem Zeiger auf diese VMT. Einige der nachfolgenden Felder innerhalb dieses Klassenrecords sind zwischen den alten Objekten und neuen Klassen identisch.

2.) Die Möglichkeit polymorphe Klassen zu benutzen. Das ist nicht identisch mit der Polymorphie innerhalb der Klassenhierarchie sondern meint das man mit variablen/dynamsichen Klassen arbeiten kann und somit dynamisch den Typ der Klasse nach der man eine Instanz/Objekt allozieren/initialkiseiren möchte.

3.) eine Klasse ist nur eine syntaktische Unterscheidung zwischen der Deklaration eines OO-Types und der daraus allozierbaren Instanzen/Objekte zur Laufzeit. Damit hat Borland das OOP Konzept nur syntaktisch "aufgeräumt" im Vergleich zu den "alten Objekten".

Sogesehen besteht der Hauptunterschied zwischen Klassen und alten Objekten in Borland Delphi nur darin das das eine veraltet ist und das Andere die konsequente Weiterentwicklung der Objekte hin zu Klassen darstellt.

Objekte konnte man von Anfang an auch im Heap dynamisch allozieren und man benutzte dazu auch Konstruktoren und Destruktoren (allerdings manuell deklariert und aufgerufen, gehörte damals zum guten Ton seine Objekte mit virtuellen Initializations-Methoden zu versehen, genannt Konstruktoren). Die vergleichbaren Destruktoren/Konstruktoren in Klassen sind im Grunde normale Klassenmethoden, also Methoden deren impliziter Parameter Self nicht auf die Instanz einer Klasse zeigt sondern auf die Klassendefinition selber, also ein Zeiger in das Codsegment in der der Compiler alles wichtige zu dieser Klasse abgespeichert hat.

Der Unterschied zwischen Konstruktoren/Destruktoren im Vergleich zu normalen Klassenmethoden besteht darin das in der VMT/DMT der Klasse keine eigenen Slots eingerichtet werden, sondern das beide Methoden innerhalb der Klassenstruktur an festem Offset ihren Zeiger auf die implementierende Methode besitzen. Das ist aber eher ein Relikt bei der Weiterentwicklung durch Borland und nicht das allgemeingültige Konzept wie man Klassen speichert. Viel öfters werden diese Spezialmethoden in anderen Sprachen genauso behandelt wie ganz normale virtuelle/dynamische Klassenmethoden. Dies zeigt sich auch darin das man in neueren Delphi Version auch diese Konstruktoren/Destruktoren überladen kann, aber das ist ein anderes Thema.

Fazit: der Unterschied zwischen Objekten und Klassen besteht darin das man Objekte nicht mehr benutzen sollte da sie durch Klassen ersetzt wurden und diese mehr können. Und zweitens räumt der syntaktische Aufbau bei einer Definition und Benutzung einer Klasse mit den Verständnisschwierigkeiten der alten syntaktischen Schreibweise der Objekte auf. Das ist übrigens der wichtigste Grund warum Klassen mächtiger sind, sie sind leichter für den Programmierer verständlich.

Das OOP Konzept der Trennnung von Klassen, darauf aufbauend Klassenhierarchien, von deren zur Laufzeit allozierten Instanzen, also Objekten, ist schon mit Borland Pascal bekannt. Aber die explizite syntaktische Trennung beider erst mit der Einführung von Klassen, also dem Bezeichner class und class of. Grundsätzlich konnte man auch mit den alten Objketen alles das machen was heutige Klassen können aber das Verständnis der Entwickler scheiterte an dem Punkt das es syntaktisch keine klare Trennung gab.

Ich habe mit den alten Objekten schon zu Zeiten von Turbo Vision unter DOS mit all den Features gearbeitet die mit heutigen Klassen so möglich sind. Nur das man heutzutage syntaktisch sauberer OO-programmiert und mit den alten Objekten eben teilweise tricksen musste. Letzendlich ist die Unterstützung des Compilers verantwortlich das man mit den alten Objekten nicht so arbeiten kann wie mit den neuen Klassen, technisch gesehen ist beides das Gleiche, ein Record aus Felder als Laufzeit Objekt der irgendwo ein Datenfeld besitzt der auf eine Record der Klasse zeigt und dieser Klassenrecord ist fix irgendwo gespeichert und enthält alles was diese Klasse so kann, sprich VMT/DMT/IntfTable/RTTI/Porperties/Events/Classname/Parentclass usw.

Auch Instanzen heutiger Klassen kann man auf den Stack allozieren, grundsätzlich kann man diese in jeder Art von Speicher allozieren, gleiches gilt für Objekte.
Und wenn der Compiler es unterstützen würde so könnte dieser auch Instanzen alloziert im Stack oder Heap autom. nach Verlassen der Scope wieder freigeben. All dies sind keine Merkmale von Klassen/Objekten oder OOP im speziellen sondern nur Merkmale inwieweit der Compiler nahtlos die OOP unterstützt.
Die alleinige Allozerbarkeit von Objekten in einem Stack widerspricht der OOP und ist unlogisch, da so die Lebenszeit einer jeden Objektinstanz immer nur lokal zur Scope der Funktion die den Stack einrichtet, beschränkt wäre. Somit musste man von Anfang an in der Lage sein Instanzen auch im Heap zu allozieren, gerade auch bei den alten Objekten, damit deren Lebenszeit unabhängig eines Stacks ist. Die Allokation von Objekten auf dem Stack ist auch keineswegs ein Vorteil. Nur weil der Compiler die implizite Freigabe solcher Objekte mit der Freigabe des lokalen Stacks uterstützt heist dies nicht das dies nun ein gewolltes Feature der Borland Entwickler war, eher ein notwendiges Übel und quasi eine Schallmauer die nur durch Allokationen im Heap durchbrochen werden konnte. Das hat auch nichts mit Garbarge Collection zu tuen, es sei denn man gibt dem Kinde "Stack" und dessen Funktionsweise lokale Resourcen beim Verlassen einer Procedure autom. wieder freigeben zu können, diesen Namen. Übrigens ebenfalls eine Erfindung unseres geehrten N.Wirths, der diese Form der Stackbehandlung als erstes in Pascal eingebaut hatte.

Zitat:

Ist aber eigentlich mächtiger als Klassen. Objects ähneln C++-Klassen: Du kannst sie sowohl auf dem Stack als auch auf dem Heap anlegen, es gibt Vererbung, virtuelle Methoden...

Nicht im entferntesten mächtiger, wenn man Klassen und Objekte überhaupt miteinander vergleichen kann. Klassen sind keine Objekte sondern eine Arbeitsvorlage für Objekte. Aus einer Klasse kann man zur Laufzeit sehr viele Instanzen/Objekte erzeugen, alle mit gleichen Klasseneigenschaften aber denoch individuell über ihre unterschiedlichen Feldinhalte.

Die Allozierbarkeit von Objekten aus Klassen ist nicht nur auf den Heap beschränkt. Überschreibt man für eine Klasse die .InitInstance und .FreeInstance Methoden dan kann man die Instazen/Objekte dieser Klasse in jedem beliebigen Speichermedium allozieren, also auch im Stack. Nur ist dies eben kein Vorteil auch wenn es C++ so macht was ja nur eine komfortablere Makroassemblersprache darstellt und keine echte Hochsprache da sind wir Delphianer doch wohl einer Meinung oder ?
[edit]
und wer sagt das Pascal Objekte denen im C++ ähneln, falsch, C++ Objekte ähneln denen vom Pascal... denn das hatte das früher
[/edit]

Gruß Hagen

[Hansa]

Moment, Moment mal. Ist wieder mal echt lustig.

Bei mir gibts das für D7 :

Delphi-Quellcode:

type

  TAusgObject = class(TObject)
    Feld1 : integer;
    constructor Create;
    destructor Destroy;
  end;

für BP7 (könnte sogar TP 5.5 sein) gabs so etwas :

Delphi-Quellcode:

ArtElementTyp = OBJECT (FensterTyp)
  Feld1 : integer;
  CONSTRUCTOR init (x1,y1,x2,y2,TextCol : byte);
(* Destructor entfällt wegen Vererbung, bereits in Grundtyp enthalten *)
END;

Also so ähnlich, wie mkinzler sagt. Und Teebee hat auch Recht, denn Markus hat tatsächlich vergessen, dass es ab TP 5.5 OOP gab und somit auch Constructor etc. Gucke dir lieber mal Kram wie inherited, override, protected etc. an.

Oh je, was hat denn Hagen da noch geschrieben ? Nene jetzt nicht mehr.

P.S.: Doch : Neugier hat gesiegt. Meine Antwort bezog sich nur auf Seite 1. Seite 2 übersehen. 8) Es ging damals bei der OOP auch um die Speicherverwaltung. Man hatte nur 640 kb also 640.000 Bytes (mehr nicht !!) Hauptspeicher, der Rest wurde dann provisorisch mit Protected Mode etc. irgendwie provisorisch gemanaged. Vermute stark, dass die für Win95 (war das D2 ?) alles umändern mussten und genau deswegen die Class eingeführt haben. Rest : siehe Hagen. @Fragesteller : warum interessiert dich das eigentlich ?

[negaH]

Nein war definitiv nicht der Grund.

Delphi-Quellcode:

type
  TMyClass = object(TObject)

definiert eben nicht den Typ eines neuen Objectes sondern eine Klasse von Objekten, aus Sicht der OOP. Klasse deshalb weil es die Vorfahrklasse mit erstmal einer Unterklasse erweitert und diese Unterklasse TMyClass kann selber als Vorfahr für eine ganze Klassenhierarchie dienen. Nicht Objekte. Erst zur Laufzeit erzeugen wir diese Objekte, als Instanzen einer Klasse.

Nun gelten OOP regeln nicht nur auf die fertigen Objekte, also Laufzeitobjekte, sondern schon bei der Typdefinition in der OOP gelten auch die Regeln der OOP. Um diesen Unterschied deutlich zu machen wurde syntaktisch durch Borland nachgebessert

Delphi-Quellcode:

type
  TMyClass = class(TObject);

TMyClass ist eine abgeleitete Klasse von der Klasse TObjekt, und dies wird hier ganz klar auch im Source deutlich. Von TMyClass kann man, muß aber nicht, zur Laufzeit nun Objekte, also Instanzen erzeugen. Der Fakt das eine solche Typdeklaration einer Klasse auch abstrakt sein kann, quasi nur eine Klasse von der man niemals echte Laufzeitobjekte erzeugen wird, zb. TCustomControl etc. pp. in der VCL, zeigt auch sehr deutlich das man die Regeln der OOP auch, bzw. gerade besonders, bei den Typdeklarationen anwendet. Man deklaraiert also nicht mehr nur einen zb. type MyInteger = Integer, sondern man Deklariert ganze Strukturen von zueinander abhängigen und immer weiter verfeinerten Klassenhierarchien und schon während dieser Typdeklaration von Nachfahren kann der Compiler assistieren, Fehler prüfen usw. Mit dem class Bezeichner hat Borland die Sache nur syntaktisch sauberer gemacht.

Weiter gehts mit dem class of

Delphi-Quellcode:

type 
  TDECCipher = class(TDECObject)
  end;
  
  TCipher_AES = class(TDECipher);
  TCipher_Blowfish = class(TDECCipher);

  TDECCipherClass = class of TDECObject;

procedure MakeSomeThing(const ADECClass: TDECCipherClass);
var
  Cipher: TDECCipher;
begin
  Cipher := ADECClass.Create;
  try
    Cipher.BlaBla;
  finally
    Cipher.Free;
  end;
end;

procedure Test;
begin
  MakeSomeThing(TCipher_AES);
  MakeSomeThing(TCipher_Blowfish);
end;

Man kann wie oben gezeigt eine Klasse auch als Variable/Parameter, eg. dynamisch zu Laufzeit benutzen. Man kann auch mit diesen Klassenvariablen, andere meinen sie als "Metaklassen" zu bezeichnen, so arbeiten das selbst die Übergabe von Klassen zur letzendlichen Erzeugung von Instanzen, gewissen OOP Regeln unterliegen. zb. wird dies benutzt um die Polymorphie der Objektinstanzen auch auf die Klassenhierarchien auszudehenen. Erst dadurch werden zb. die DFMs Streams, also das VCL Streaming System, überhaupt erst möglich.

All diese neuen Features hätte man auch in die, bzw. genauer um die, bestehenden alten Objekte bauen können und diese dann zu den heutigen Klassen ausbauen können. Genauergesagt hat dies Borland sogar exakt so gemacht. Die Klassenrecords im Codesegement, die also eine Klasse beschreiben, bestehen ab Offset 0 aus den gleichen Daten wie bei den alten Objekten. Vor dem Offset 0, also mit negativen Offsets stehen bei Klassen aber nun noch mehr Sachen. Borland hat also die alten Objekte aufgebohrt zu Klassen. Innerhalb der Klassenrecords wurde das neue Feature -> RTTI -> auch noch angewendet, so das dieses ehemals nicht OOP Feature heutzutage eben eine Grundlage der OOP darstellt, um zb. neuere Möglichkeiten der Klassen, wie Properties usw. unterstützen zu können.

Im gleichen Atemzug hat Borland nun auch die Syntax geändert, was schlußendlich auch das Hauptziel war. Die Syntax mit den Klassen spiegelt einfach die OOP besser und leichter verständlich wieder. Sie trennt zwei wichtige Aspekte der OOP auch syntaktisch deutlich, die Deklaration von Typen der OOP also einer Klassenhierarchie und deren Benutzung zur Laufzeit als Instanzen=Objekten dieser Klassenhierarchie. Der Bezeichner object macht dies eben nicht deutlich, bzw. ist im Sinne der OOP ein falscher Name für einen Bezeichner der eine Klassenhierarchie deklariert.

Mit dem Speichermanegement hat dies im Grunde nichts zu tuen. Man kann Instanzen zur Laufzeit beliebig allozieren, im Stack oder Hauptspeicher, ist egal. Man kann auch die Klassenrecords durch den Compiler an beliebiger Stelle abspeichern, muß also nicht wie in Delphi im Codesegment liegen, was aber sinnvoll ist. Eine Klasse lässt sich auch im Stack oder Heap dynamisch zusammenschustern zur Laufzeit. Diese Möglichkeit habe ich benutzt um zur Laufzeit aktiv das Verhalten einer Klasse, und damit all derer Instanzen, zu beeinflussen.

Gruß Hagen