Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Pointer beim Komponentenprogrammieren (https://www.delphipraxis.net/35343-pointer-beim-komponentenprogrammieren.html)

Jens Schumann 6. Dez 2004 12:03

Re: Pointer beim Komponentenprogrammieren
 
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 6. Dez 2004 12:11

Re: Pointer beim Komponentenprogrammieren
 
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 6. Dez 2004 12:22

Re: Pointer beim Komponentenprogrammieren
 
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. 6. Dez 2004 15:26

Re: Pointer beim Komponentenprogrammieren
 
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]


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:33 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz