"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?