"Unbekannter Bezeichner" bei Eigenschaft eines Objektes

[BillieJoe90]

Hallo,
ich habe folgenden Code in einer seperaten Unit:

Delphi-Quellcode:

  type TFeld = class(TObject)
  public
    Name:String;
    Bild:TPicture;
    FeldNr:Integer;
  private

  end;

  TGrundstueck = class(TFeld)
  public
    Preis:Integer;
  private

  end;

In der "Haupt-Unit" dann folgendes:

Delphi-Quellcode:

procedure TSpielbrett.FormCreate(Sender: TObject);
var 
  iniFile: TIniFile;
  FeldNr2:TFeld;
begin
  FeldNr2 := TGrundstueck.Create();
  FeldNr2.Name       := iniFile.ReadString('Feld2', 'Name', 'Braun1');
  FeldNr2.Preis      := iniFile.ReadInteger('Feld2', 'Preis', 1200);
end;

Die Eigenschaft Preis ist ihm nicht bekannt, Name aber wohl.

Ich kann mir das nicht erklären, weil man solche Probleme als PHP-Programmierer nicht kennt :lol:
Die Eigenschaft ist doch unter public deklariert und selbst die geerbten Eigenschaften kennt er ja.

Kann mir jemand helfen?

Danke schonmal!

Johannes

[bttb930]

FeldNr2 musst Du als TGrundstueck deklarieren.

Oder den Typ casten:

Delphi-Quellcode:

(FeldNr2 as TGrundstueck).Preis :=

Vergiss Vergleiche mit PHP: PHP ist bei der Objektorientierung nicht sehr gut implementiert. Vieles geht nicht und vieles anderes geht falsch.

[Der_Unwissende]

Zitat:

Zitat von BillieJoe90

Die Eigenschaft Preis ist ihm nicht bekannt, Name aber wohl.

Ich kann mir das nicht erklären, weil man solche Probleme als PHP-Programmierer nicht kennt :lol:
Die Eigenschaft ist doch unter public deklariert und selbst die geerbten Eigenschaften kennt er ja.

Hi,
eigentlich sollte das Problem hier in jeder Objekt Orientierten Sprache auftauchen. Dein FeldNr2 ist vom Typ ein TFeld, es sind für diese Variable also alle Eigenschaften von TFeld vorhanden (dass sagst du dem Compiler). Erzeugen tust du ein TGrundstueck. Der Compiler schaut nun, ob ein TGrundstueck mind. alle Eigenschaften eines TFeld hat. Erzeugst du direkt eine Instanz der Klasse, von deren Typ die Variable ist (also TFeld.Create) oder von einer Klasse die von ihr erbt, so wird der Compiler nicht meckern (analog bei einem Interface IFeld und allen Klassen die es implementieren oder von einer Klasse erben die es implementiert).

Das du in FeldNr2 ein spezielles TFeld speicherst ist Delphi egal. Du sagst schließlich, dass du nur die Eigenschaften eines TFeld verwenden möchtest. Genau hier liegt auch der Sinn der OOP. Du brauchst halt kein Detailwissen über alle möglichen Implementierungen. Du solltest dir also mal ein wenig zum Theme OOP anschauen, dann verstehst du schnell wann du welchen Variablentyp verwendest!

Gruß Der Unwissende

[r2c2]

Das eigentliche Problem haben ja schon bttb930 und Der Unwissende erläutert, trotzdem hier nochmal n Hinweis:

Man sollte - sowohl in PHP, alsauch in Delphi - keine public fields anlegen. Warum? Lies dir mal folgenden Text durch: http://tut.php-q.net/klassen.html Insbesonder Kapitel 6. Is sogar PHP, lässt sich aber leicht auf Delphi übertragen...

mfg

Christian

[BillieJoe90]

Zitat:

Zitat von bttb930

FeldNr2 musst Du als TGrundstueck deklarieren.

Oder den Typ casten:

Delphi-Quellcode:

(FeldNr2 as TGrundstueck).Preis :=

Vergiss Vergleiche mit PHP: PHP ist bei der Objektorientierung nicht sehr gut implementiert. Vieles geht nicht und vieles anderes geht falsch.

Ja, das funktioniert. Aber ehrlich gesagt möchte ich das nicht immer so schreiben :wink:
Gibt es eine Möglichkeit, das irgendwie einmal zu casten und von da an ist es gecastet und ich muss nur `"FeldNr2." schreiben?

[r2c2]

Deklariers einfach als TGrundstück. Und wenn du das nicht willst, mach ne 2. Variable:

Delphi-Quellcode:

var
  f: TFeld
  g: TGrundstueck;
begin
  ...
  g := (TFeld as TGrundstueck);

mfg

Christian

[Elvis]

Woür die Klammern? Sieht doch doof aus. ;)
@Billie, was du da erlebt hast ist die statische Typensicherheit von kompilierten Programmen verglichen mit dem Ducktyping von interpretierten Skriptsprachen.
Der Vorteil hier it, dass du seltener Probleme haben wirst, dass dir das Programm zur Laufzeit um die Ohren fliegt. Der Compiler kann viele Dinge schon beim Überetzen abfangen und bemängeln.

[BillieJoe90]

Zitat:

Zitat von Elvis

Woür die Klammern? Sieht doch doof aus. ;)
@Billie, was du da erlebt hast ist die statische Typensicherheit von kompilierten Programmen verglichen mit dem Ducktyping von interpretierten Skriptsprachen.
Der Vorteil hier it, dass du seltener Probleme haben wirst, dass dir das Programm zur Laufzeit um die Ohren fliegt. Der Compiler kann viele Dinge schon beim Überetzen abfangen und bemängeln.

Also die paar Exception-Prüfungen würde ich in Kauf nehmen, um nicht diese stressige "Typen-Gebundeheit" zu haben...

[xaromz]

Hallo,

Zitat:

Zitat von BillieJoe90

Also die paar Exception-Prüfungen würde ich in Kauf nehmen, um nicht diese stressige "Typen-Gebundeheit" zu haben...

Diese 'stressige Typen-Gebundenheit' ist aber doch genau einer der wesentlichen Vorteile. .Net geht hier sogar noch viel weiter. Es ist doch immer besser, Fehler gar nicht erst zuzulassen, als mit Exceptions hinterherzuräumen. Außerdem sollen Exceptions ja Ausnahmen sein, und nicht die Regel :zwinker: . Es sollte also niemals einem Delphi-Programmierer passieren, dass ein Cast eine Exeption wirft, sonst hat er etwas grundlegendes falsch gemacht.
Die strikte Typen-Gebundenheit hilft Dir übrigens auch beim Programmieren. Denn wenn die IDE nicht weiß, welcher Typ sich hinter der Variable befindet, kann sie Dir auch nicht unter die Arme greifen.

Gruß
xaromz

[BillieJoe90]

Mir ist grad eine Idee gekommen, aber ich bezweifle, dass das um zu setzen ist:
Gibt es in Delphi die Möglichkeit, einen "Link" zu setzen. Jetzt mal ein Beispiel:

Delphi-Quellcode:

procedure Irgendwas();
  var
    Feld:Array[1..41] of Link; //oder wie es halt heißt...
    Feld1:TGrundstueck;
    Feld2:TWasAnderes;
begin
  Feld[1] := Feld1;
  Feld[1].methodeVonTGrundstueck();
end;

Versteht ihr, was ich meine?

[mkinzler]

Nein, das geht so nicht. Du solltset dich mal mit den Grundlagen der OOP beschäftigen, dann wirst du dessen Vorteile schnell zu schätzen wissen.

[xaromz]

Hallo,

Zitat:

Zitat von BillieJoe90

Mir ist grad eine Idee gekommen, aber ich bezweifle, dass das um zu setzen ist:
Gibt es in Delphi die Möglichkeit, einen "Link" zu setzen.

Das geht durchaus. Nennt sich Pointer. Jedes Objekt ist eigentlich ein Pointer.

Zitat:

Zitat von BillieJoe90

Jetzt mal ein Beispiel:

Delphi-Quellcode:

procedure Irgendwas();
  var
    Feld:Array[1..41] of Link; //oder wie es halt heißt...
    Feld1:TGrundstueck;
    Feld2:TWasAnderes;
begin
  Feld[1] := Feld1;
  Feld[1].methodeVonTGrundstueck();
end;

Versteht ihr, was ich meine?

Das Problem ist, dass Du dann (wenn Du Link durch Pointer ersetzt) wieder nur einen untypisierten Pointer hast. Du musst also das Array so deklarieren:

Delphi-Quellcode:

Feld:Array[1..41] of TGrundstueck;

Denn da Delphi keine Interpretersprache ist, gibt es auch niemanden, der zur Laufzeit den Typ ermitteln kann.

Gruß
xaromz

[BillieJoe90]

Ich krieg die Krise... :wall:
Aber danke trotzdem für die Antworten!

Sprich, mein Problem ist "unlösbar"? :(

[mkinzler]

Zitat:

Sprich, mein Problem ist "unlösbar"? Sad

Dein Problem ist nicht wirklich ein Problem.

Das Prinzip der OOP ist, daß abgeleitetet Klassen, sich wie ihre Superklassen verhalten können und nicht umgekehrt.

Du könntest höchstens alle Eigenschaften der (abgeleiteten) Klassen in die Superklasse packen :

Statt
TSuperKlasse
-allg. Eigenschaften
-allg. Methoden
-> TSpezKlasse1
-Eigenschaften Spez1
-Methoden Spez1
-> TSpezKlasse2
-Eigenschaften Spez2
-Methoden Spez2

also
TIchScheissAufOOP_Klasse
-allg. Eigenschaften
-allg. Methoden
-Eigenschaften Spez1
-Methoden Spez1
-Eigenschaften Spez2
-Methoden Spez2

[xaromz]

Hallo,

Zitat:

Zitat von BillieJoe90

Ich krieg die Krise... :wall:

Immer locker bleiben :wink:

Zitat:

Zitat von BillieJoe90

Sprich, mein Problem ist "unlösbar"? :(

Ich weiß nicht. Was ist denn Dein Problem?

Gruß
xaromz

[bttb930]

Zitat:

Zitat von BillieJoe90

Aber ehrlich gesagt möchte ich das nicht immer so schreiben

Tja... was soll man dazu sagen??

Was greifst Du auch auf ein Feld zu, das TFeld nicht besitzt? Das ist soundso schon nicht sehr objektorientiert. Vielleicht ist es am besten, wenn Du einfach prozedural programmierst - Objektorientierung sieht nämlich komplett anders aus als Dein Code.

[BillieJoe90]

Zitat:

Zitat von xaromz

Hallo,

Zitat:

Zitat von BillieJoe90

Ich krieg die Krise... :wall:

Immer locker bleiben :wink:

Zitat:

Zitat von BillieJoe90

Sprich, mein Problem ist "unlösbar"? :(

Ich weiß nicht. Was ist denn Dein Problem?

Gruß
xaromz

Mein Problem ist, dass ich Monopoly programmiere und für jeden Typ von Feld eine eigene Klasse haben möchte, trotzdem die Felder aber per Feld[i] anwählen können möchte.
Wenn mir keiner helfen kann, mache ich es so, dass eine Klasse für alle da ist und je nachdem, was für einen Typ die Instanz hat, reagieren die Methoden... Nicht sonderlich elegant, aber es wird nicht anders gehen...

[mkinzler]

Zitat:

Mein Problem ist, dass ich Monopoly programmiere und für jeden Typ von Feld eine eigene Klasse haben möchte, trotzdem die Felder aber per Feld[i] anwählen können möchte.

das kannst du doch problemlos, nur wenn du spezielle Eigenschaften bzw. Methoden der speziellen Klasse verwenden willst, mußt du dem Compiler halt sagen, daß er die Instanz als solche betrachten soll. Woher soll er es denn sonst wissen?

[bttb930]

Zitat:

Zitat von BillieJoe90

Mein Problem ist, dass ich Monopoly programmiere und für jeden Typ von Feld eine eigene Klasse haben möchte, trotzdem die Felder aber per Feld[i] anwählen können möchte.
Wenn mir keiner helfen kann, mache ich es so, dass eine Klasse für alle da ist und je nachdem, was für einen Typ die Instanz hat, reagieren die Methoden... Nicht sonderlich elegant, aber es wird nicht anders gehen...

Na, grundsätzlich kann man das so machen, man muss aber die Arbeit DELEGIEREN! Das heißt:

NICHT je nach Typ dies oder das tun

SONDERN unabhängig vom Typ immer das gleiche tun - das ist aber bei jedem Typ anders deklariert.

Dies machst Du mit virtuellen Methoden:

Delphi-Quellcode:

type
  TPerson = class
  private 
    FName: string;
  public
    property Name: string read FName write FName;
  end;

  TCommonField = class
  private
    ...
  public
    procedure Enter(APerson: TPerson); virtual; abstract;
  end;

  TNorthStation = class(TCommonField)
  private
    ...
  public
    procedure Enter(APerson: TPerson); override;
  end;

  TKnast = class(TCommonField)
  private
    ...
  public
    procedure Enter(APerson: TPerson); override;
  end;

...

procedure TNorthStation.Enter(APerson: TPerson);
begin
  ShowMessage(APerson.Name + ' auf Nordbahnhof');
end;

procedure TKnast.Enter(APerson: TPerson);
begin
  ShowMessage(APerson.Name + ' im Knast');
end;

var
  Person1: TPerson;
  Knast: TKnast;
  Nordbahnhof: TNorthStation;
  Feld: TCommonField;
begin
  Person1 := TPerson.Create;
  Person1.Name := 'Billy Joe';
  Knast := TKnast.Create;
  Nordbahnhof := TNorthStation.Create;

  Feld := Knast;
  Feld.Enter(Person1);
  
  Feld := Nordbahnhof;
  Feld.Enter(APerson);
end;

Die beiden Enter-Methoden sind jeweils anders implementiert. In deiner Prozedur bekommst Du ein Field: TCommonField und rufst lediglich Field.Enter(APerson) auf. Fertig.

[BillieJoe90]

An bttb930:
Das sieht gut aus :)
Aber folgende Fehlermeldungen: :gruebel:

Undefinierter Bezeichner 'ShowMessage'
Undefinierter Bezeichner 'ShowMessage'

[bttb930]

cursor auf showmessage plazieren, F1 drücken und da steht dann welche unit du noch einbinden musst. ich glaube Dialogs.

[BillieJoe90]

Danke Leute! Ihr habt mir alle wirklich sehr sehr weiter geholfen! Es läuft jetzt alles so, wie ich mir das vorgestellt habe! :dp: :cheers:
Schön geordnet in Klassen lässt sich doch schon um einiges besser arbeiten, als prozedural :)