Pointer beim Komponentenprogrammieren

[F.W.]

Hallöle alle miteinander und nen schönen 2. Advent erstmal :-D !

Aber jetzt zu meinem Problemchen:
Sitze gerade mal wieder an einer Komponente. Die Kompo hat unter anderem folgendes property:

Delphi-Quellcode:

  private
    FGrid: TStringGrid;
  published
    property Grid: TStringGrid read FGrid write FGrid;

Wenn ich jetzt im weiteren Quelltext der komponente auf die StringGrid zugreifen möchte, muss ich dann FGrid oder Grid benutzen?

Also z.B.:

Delphi-Quellcode:

if FGrid <> NIL then
   FGrid.Cells[X, Y] := 'XY';

//oder

if Grid <> NIL then
   Grid.Cells[X, Y] := 'XY';

Danke schonmal!

[Helmi]

du musst:

Code:

if FGrid <> NIL then 
   FGrid.Cells[X, Y] := 'XY';

benutzen

[SirThornberry]

es ist egal. du kannst auch "Grid" benutzen da "Grid" auf "fGrid" verweist. Richtiger ist es "fGrid" zu nutzen.

[glkgereon]

Zitat:

Richtiger ist es "fGrid" zu nutzen.

und noch besser wäre
"Besser ist es "fGrid zu nutzen" :mrgreen: :warn:

aber abgesehen davon:
ich hätte spontan gesagt
"nimm Grid, weil wenn du schonmal ne property gemacht hast, kannst du die ja auch nutzen"...oder nicht?

[teebee]

Genaugenommen ist der direkte Zugriff auf die Eigenschaftsdaten falsch:

Zitat:

Zitat von Online-Hilfe

Wenn eine Methode oder eine andere Eigenschaft diese Daten ändern muß, muß dies über die Eigenschaft und nicht über einen direkten Zugriff auf die gespeicherten Daten erfolgen. Dadurch ist sichergestellt, daß die Implementierung einer geerbten Eigenschaft geändert werden kann, ohne daß dabei abgeleitete Komponenten ungültig werden.

Gruß, teebee

[Chewie]

Zitat:

Zitat von teebee

Genaugenommen ist der direkte Zugriff auf die Eigenschaftsdaten falsch:

Falsch ist es im Sinne der objektorientierten Programmierung. Und darüber hinaus ist es schwachsinnig. Du definierst dir deine Property ja, um nicht über das Objektfeld zu gehen. Darüber hinaus ist das Feld ja privat. Solange du in der gleichen Unit bist, kannst du zwar auch private Felder anderer Klassen verändern, aber das ist ja nur ein Zugeständnis an das C++-Konzept der Friends. Spätestens wenn du in einer anderen Unit auf deine Klasse zugreifst, wirst du Probleme kriegen.

[F.W.]

Also die letzten 2 Posts versteh ich nicht ganz, speziell das letzte:
Beim Componentenproggen muss man doch als Eigenschaft
property X: Integer read FX write FX
das dann auf eine privatedeklarierte Variable mit (vorbildlich) F vorangestellt, damit man den Überblick leichter halten kann.
Wie soll ich denn sonst eine Grid hinbekommen, die man bei bedarf mit aufs Formular setzt und dann in meiner Komponente auf sie Verlinkt? :gruebel:

[dizzy]

Sauber wäre es dann, wenn du innerhalb der Implementierung der Klasse ihre private-Variable "FGrid" ansprichst, aus allen anderen Klassen heraus aber die Property "Grid". Auch wenn sie in der selben Unit liegen!
Das ist dem OOP-Konzept imho am besten zuträglich.

[teebee]

Zitat:

Zitat von dizzy

Sauber wäre es dann, wenn du innerhalb der Implementierung der Klasse ihre private-Variable "FGrid" ansprichst

Ganz sauber wird es erst, wenn das private Feld nur in den Get/Set-Methoden der Property angesprochen wird und an allen anderen Stellen in der Klasse über die Property gegangen wird.

Gruß, teebee

[Sanchez]

Zitat:

Zitat von teebee

Ganz sauber wird es erst, wenn das private Feld nur in den Get/Set-Methoden der Property angesprochen wird und an allen anderen Stellen in der Klasse über die Property gegangen wird.

Würd ich auch sagen. Ansonsten kanns ganz schnell unübersichtlich werden. In dem konkreten Beispiel ist eigentlich egal, weil die Property sowieso direkt auf die Variable zeigt.
Ich würd trotzdem über die Property gehen.

grüße, daniel