AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign In Klasse auf Funktion zugreifen oder auf Property?
Thema durchsuchen
Ansicht
Themen-Optionen

In Klasse auf Funktion zugreifen oder auf Property?

Ein Thema von norwegen60 · begonnen am 29. Mär 2018 · letzter Beitrag vom 4. Apr 2018
Antwort Antwort
Seite 2 von 2     12   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#11

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 18:04
Ich halte es eher mehr nach Nice-Code.
Wenn diese "Funktion" logisch zu einer Reihe anderer Property gehört, dann mach ich das als ReadOnly-Property, damit es sich in der Klassendeklaration ansehnlicher einfügt.
Im Programmablauf ist es egal, da der Compiler das Property durch die Funktion ersetzt hat.

UND bei Custom-Klassen mach ich es eben so, denn Property kann man später in der Sichtbarkeit einfach verschieben.


Zitat:
Zusätzlich noch mit class und static/inline deklarationen.
Das Zusätzlich war falsch und kann hier auch falsch sein,
wenn auf Daten der Objektinstanz zugegriffen werden soll.

class function = Methode an der Klasse (nur globale Funktion ohne Bindung an eine Instanz)
function = Methode am Objekt, inkl. Zugriff auf Felder/Methoden dieser Instanz

static = statische Funktion > ohne SELF-Variable
Hier hat man nichtmal mehr Zugriff auf den aktuellen Klassentyp, bei abgeleiteten Klassen.
> der implizite SELF-Parameter wird nicht übergeben, was den Funktionsaufruf kleiner macht
> Letztendlich ist der Aufruf genau so, wie bei einer "normalen" Funktion, welche nicht in einer Klassendefinition steckt (zuzüglich Zugriff auf z.B. Class-Vars)
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu ( 3. Apr 2018 um 18:08 Uhr)
  Mit Zitat antworten Zitat
günni0
(Gast)

n/a Beiträge
 
#12

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 18:09
Zitat:
> Letztendlich ist der Aufruf genau so, wie bei einer "normalen" Funktion, welche nicht in einer Klassendefinition steckt (zuzüglich Zugriff auf z.B. Class-Vars)
Richtig. Ist auch immer mein Ziel. Das mit Class usw. hat den Vorteil, dass man die Unit umbenennen kann, ohne an zig-Stellen was abändern zu müssen.
Ich persönlich benenne Units oft um. Weniger oft jedoch record- und class-Namen.

Record benutze ich, um den ganzen Clutter der Codecompletion drum herum wegzubekommen.
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.490 Beiträge
 
Delphi 7 Professional
 
#13

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 18:26
Der Sinn von Properties in Delphi erschließt sich mir bis heute nicht. ...
Properties sind nur noch mehr Schreibarbeit. Gewonnen hat man dadurch nichts.
Also sowas finde ich mit Properties viel schöner als ohne:
Delphi-Quellcode:
Label.Caption := Label.Caption + '*';

// statt
var
  s : String;
begin
  s := Label.GetCaption;
  s := s + '*';
  Label.SetCaption(s);
end;

// ok, das ginge wohl auch:
Label.SetCaption(Label.GetCaption + '*');
Mir gefällt die erste Variante am Besten, da sie im Quelltext am leichtesten zu lesen ist.

Und beim Programmieren interessiert es mich nicht, ob es einen Setter und einen Getter gibt. Mir reicht es, wenn ich eine Eigenschaft einfach per Zuweisung mit 'nem Wert versehen kann, ob das intern über 'nen Getter und 'nen Setter (oder jeweils nur einen davon) abläuft, interessiert mich nicht.

Baut jemand eine Klasse, bei der es für eine Eigenschaft weder Setter noch Getter gibt, so kann ich da einen Wert zuweisen.
Baut jetzt jemand später Getter und Setter ein und ich kann nur diese nutzen, so fällt eine Änderung des Quelltextes an.

Bei der Nutzung von Eigenschaften ist das für den Programmierer transparent. Die Sichtbarkeit läßt sich bei der Vererbung leicht verändern, aber über weitere interne Änderungen muss ich mir da keinen Kopp machen. Das ist innerhalb der Klasse und sollte nach außen keine Änderungen am Quelltext erforderlich machen.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.159 Beiträge
 
Delphi 10 Seattle Enterprise
 
#14

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 18:42
Bei einer Methode mit get oder set im Namen sehe ich ob es ums Lesen oder Schreiben geht. Bei einer Property weiß ich erst dass Schreiben nicht geht wenn ich F9 gedrückt, ein paar Sekunden Däumchen gedreht habe und dann unten in der Textbox eine Fehlermeldung erscheint.

Über die Jahre gerechnet habe ich damit bestimmt schon mehrere Tage Arbeitszeit gespart
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#15

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 19:23
Bei einer Property weiß ich erst dass Schreiben nicht geht wenn ich F9 gedrückt,
CodeInsight, HelpInsight, eventuell die Dokumentation (DocuInsight) und sogar die CodeCompletation hätten dir das auch sofort verraten.
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.159 Beiträge
 
Delphi 10 Seattle Enterprise
 
#16

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 3. Apr 2018, 19:43
Ist Code Insight nicht die Code Completion?

Wie auch immer, ich bin zu dumm zu sehen wo man sich das herleiten könnte.
Miniaturansicht angehängter Grafiken
derp.jpg  
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
555 Beiträge
 
Delphi 10.3 Rio
 
#17

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 4. Apr 2018, 17:19
Für eine Property wird/wurde RTTI generiert (Hinweis auf published). Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen. Das hat dazu geführt, dass das Konzept ein wenig überstrapaziert wurde.

Properties sind uralt und waren tatsächlich gedacht für Datenvalidierung im Falle von Verbundstrukturen. Das Konzept der Property ist so alt, da gab es grad mal Klassen in Smalltalk in den Papers.

Du kannst die interne Repräsentation eleganter von der Außenwelt verstecken. Du weist String zu und speicherst intern bspw. eine exaktere Struktur.

Wenn du nur lesend zugreifst mache einfach eine Funktion.

Geändert von MichaelT ( 4. Apr 2018 um 17:32 Uhr)
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
555 Beiträge
 
Delphi 10.3 Rio
 
#18

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 4. Apr 2018, 17:59
Gar nicht . Allein kannst du nicht verhindern, dass die Left Side angeboten werden muss. Woher sollte die IDE wissen, dass du hernach eine Zuweisung schreibst.

Delphi und das durchsuchen der generelleren Klassen . Warum kommt mir die Büchse der Pandorra in den Sinn.

Der MMX zeigt es an, aber ansonsten ... mhhh.

Verwende Property nicht als Teil des Klassennames wenn du CNPack nimmst.

Ist Code Insight nicht die Code Completion?

Wie auch immer, ich bin zu dumm zu sehen wo man sich das herleiten könnte.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#19

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 4. Apr 2018, 18:07
Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen.
Und man sieht es im Objektinspector.

Das kann auch für ReadOnly-Property gut sein. z.B. um dort einen internen Komponenten-Status oder die Verison anzuzeigen.


Und selbst Write-Only-Property gibt es, die manchmal ganz nett sind.
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
555 Beiträge
 
Delphi 10.3 Rio
 
#20

AW: In Klasse auf Funktion zugreifen oder auf Property?

  Alt 4. Apr 2018, 19:04
Die Properties sind ursprünglich zumeist Ganzzahlwerte oder Zeichenketten in Datenbanken (Systeminformation) in geschützten Speicherbereichen und vorzüglich Konfigurationsparameter. Weswegen die Entsprechung mit published im Kontext der IDE an sich stimmig ist.

Wenn du wirklich ein Framework dicht machen willst und gegen insbesondere unbewusste missbräuchliche Verwendung durch andere Team Mitglieder schon während der Entwicklung willst schützen musst du am Ende auf C/C++ zurückgreifen. Das ist zumeist ein Overkill. Für die gebräuchliche Verwendung ist im Delphi genug da.

Die meisten Sachen grad im Zusammenhang mit Vererbung und Delphi bspw. sind in der Praxis nicht relevant, da eine Klassenbibliothek nicht viel mehr als 4 (bis max 7 im Ausnahmefall) Vererbungstiefe sollte aufweisen. Respektive war als Delphi das Licht der Welt erblickte diese Forderung eher eine technische Notwendigkeit, aber nicht nur. die Forderung hat aber auch mit Übersichtlichkeit zu tun. Damit relativiert sich viel. Die Verantwortlichkeit ist eben sauberer abgebildet.

Jetzt werden gleich die ersten schreiben. 'Aber es darf nur einen Ort gehen an dem etwas im Programm passiert'. Das stimmt zwar, kommt aber ursprünglich aus dem systemischen Zugang zu modularen Systemen. In der echten 'OO' ist der eine Platz einfach im Kontext einer Klasse oder einem Objekt definiert welches zuständig ist. Die Hybridsprachen müssen das alles eher in der Vererbungshierarchie abbilden. Die sind ewig auf der Suche nach dem zuständigen Typen und fragen nicht einfach ein Objekt von dem sie glauben oder wissen.

So irr wie das ganze heute betrieben wird in der Objektorientierung hat auch nie jemand verlangt.

Die Java Leute haben mit den Design Patterns im Java Framework angefangen und MS hat das ganze zur Perversion getrieben. HIT ist der Standardimplementierungsmehtode, fast alles ist abgesichert bis zum Abwinken und von IDE der unterstützt. Sowie da.

Es geht heut keiner mehr her und sagt, 'Jetzt haben wir einen netten Code geschrieben und freuen uns, dass dieser sogar funktioniert'.

Die IT war schon mal gemütlicher und damals hat man sich mehr Gedanken drüber gemacht wie man sich Arbeit erspart. Diese Denke war/ist im Delphi Umfeld sehr verbreitet.

Im Ferrari einen Marathon zu fahren ist auch nicht sportlicher als gleich einen 100m Sprint laufen.


Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen.
Und man sieht es im Objektinspector.

Das kann auch für ReadOnly-Property gut sein. z.B. um dort einen internen Komponenten-Status oder die Verison anzuzeigen.


Und selbst Write-Only-Property gibt es, die manchmal ganz nett sind.

Geändert von MichaelT ( 4. Apr 2018 um 19:17 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz