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

[Jens Schumann]

Hallo,
dem kann ich nur zustimmen

Zitat:

Zitat von 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.

Damit mein Posting auch etwas Mehrwert enthält hier eine Gegenfrage:
Hast die Methode Notification des Vorfahren überschrieben?
Wenn nein kann es innerhalb der IDE zu schweren Schutzverletzungen kommen ein TStringGrid,
dass mit Komponente verlinkt ist, gelöscht wird.

[dizzy]

Zitat:

Zitat von 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

Das fordert meines Wissens nach die OOP nicht so strikt. Es ist imho nur so geregelt dass man von ausserhalb einer Klasse keinen direkten Zugriff auf die Felder haben soll. Wie man in der Klasse selbst zugreift ist frei, und direkt auch noch einiges performanter als mit Umweg über Getter/Setter (die in Delphi dank der Properties ja nichtmal zwingend sind).
Zumal mit deiner Variante die Getter/Setter ihrer Existenzberechtigung enthoben würden (wenn es nur um einfache Wertzuweisung geht!). Dann kann ich genau so gut ein public-Feld nehmen ;).

[ot] Ich frage mich ohnehin warum das Geheimnisprinzip bei der OOP so überaus wichtig sein soll. Wenn es um Felder geht denen einfach zugewiesen wird, und die auch weiter vererbt werden sollen, warum dann nicht public? Ich mach's zwar auch nicht, aber warum ist das so? Nur damit die armen C'ler und Javaisten (C# mal ausgenommen) die von Properties nur träumen können immer schön einheitlich "SetXXX()" schreiben können, und nicht mal "SetVar(Wert)" und mal "Var = Wert"?
Irgendwie doof :D
[/ot]

Der Propertyzugriff ist imho ohnehin eines der tollsten Features der DL!

[nailor]

meiner meinung nach die daten direkt nur da wo unabdinglich (bei der implementation der property) verwenden und an allen anderen stellen die property zu nutzen. die einzige mir bekannt ausnahme besteht da, wo es _wirklich_ auf speed ankommt, und der property-overhead stören würde. das ist aber bei 08/15 fällen nie der fall.

[F.W.]

Zitat:

Hast die Methode Notification des Vorfahren überschrieben?
Wenn nein kann es innerhalb der IDE zu schweren Schutzverletzungen kommen ein TStringGrid,
dass mit Komponente verlinkt ist, gelöscht wird.

Nööö :lol: hab ich nicht!
Und ja, du hast recht, es kommt zu Zugriffsverletzungen.
In der Kompo stekt noch ein propery, dass die Spaltenzahlen angibt, allerdings nicht nur für die Grid, die Grid ist ja nur zusätzlich zur Ausgabe. Wenn also das Property in der Designtime verändert wird, wird auf die Grid zugegriffen, ihre Spaltenzahl verändert und sie wird mit nullen gefüllt (in jede Zelle eine "0").
Das Spaltenändern macht er noch, das sieht man ja, aber mit nullen füllen scheint nicht zu funktionieren, ich kann nichts genaueres sagen,
[ot]
ich nicht weiß wie oder besser nicht weiß ob überhaupt: man bei Komponenten in der Designtime Haltepunkte setzt oder so was in der Art, wie kann ich rausbekommen, was das für ein Fehler ist oder welcher? Zugriffsverletzung an Adresse xxx sagt mir nicht viel! Kann man da irgendwie nachgucken?
[/ot]