AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Sinn einfacher Getter und Setter

Ein Thema von masc-online · begonnen am 18. Apr 2019 · letzter Beitrag vom 25. Apr 2019
Antwort Antwort
Seite 2 von 2     12   
Rollo62

Registriert seit: 15. Mär 2007
4.096 Beiträge
 
Delphi 12 Athens
 
#11

AW: Sinn einfacher Getter und Setter

  Alt 18. Apr 2019, 13:23
Dem unten Gesagten kann ich voll zustimmen.

Bei solchen simplen Typen ist das auch mehr oder weniger Egal, aber

Delphi-Quellcode:
procedure TTestClass.SetTest3(const AValue: TMyComplexClass);
begin
  if (FTest3 <> AValue) then
    FTest3.Assign( AValue );
end;
bei komplexen Assignments kann es erheblich Performance kosten wenn man immer nur blind kopiert, statt vorher auf Änderung zu Testen.

Um mir darum nicht jedes Mal Gedanken zu machen lege ich auch meistens standardmäßig Getter/Setter an,
das ist Dank Ctrl-C und/oder dem MMX-Tool ja auch kein großes Tipp-Problem mehr.
  Mit Zitat antworten Zitat
Benutzerbild von blawen
blawen

Registriert seit: 1. Dez 2003
Ort: Luterbach (CH)
677 Beiträge
 
Delphi 12 Athens
 
#12

AW: Sinn einfacher Getter und Setter

  Alt 18. Apr 2019, 18:42
das ist Dank Ctrl-C und/oder dem MMX-Tool ja auch kein großes Tipp-Problem mehr.
Mit dem Klassen-Explorer ist dies von Hause aus machbar.
Roland
  Mit Zitat antworten Zitat
Benutzerbild von masc-online
masc-online

Registriert seit: 10. Dez 2005
Ort: Leinfelden-Echterdingen
22 Beiträge
 
Delphi 11 Alexandria
 
#13

AW: Sinn einfacher Getter und Setter

  Alt 18. Apr 2019, 18:52
Danke für die Antworten und die rege Beteiligung.
Marian
«Sei nie zufrieden, aber immer glücklich, mit dem was du tust!»
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie
Online

Registriert seit: 12. Aug 2003
Ort: Soest
4.017 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#14

AW: Sinn einfacher Getter und Setter

  Alt 19. Apr 2019, 14:03
Aber es macht ja keinen Unterschied, ob man eine Property von einem direkten Lese-/Schreibvorgang auf das private Feld auf eine Funktion/Prozedur umstellt oder den Inhalt der Funktion/Prozedur ändert; beides ist eine Veränderung des Codes.
Falsch. Ersteres ist ein binary breaking change der API.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.858 Beiträge
 
Delphi 11 Alexandria
 
#15

AW: Sinn einfacher Getter und Setter

  Alt 19. Apr 2019, 14:18
Zitat:
Falsch. Ersteres ist ein binary breaking change der API.
Für den "Aufrufer" ist es aber egal, was der Compiler daraus macht. Er muss seinen Code auch nicht ändern.

Aus dem Code des "Konsumenten":

Messias.Name := 'Jesus'; wird im 1. Fall

Messias.FName := 'Jesus'; und nachh der Umstellung der Implemenierung auf Getter dann

Messias.setName ('Jesus'); Das ist natürlich eine Veränderung des Binärcodes, aber kein Verhalten der "black box".
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie
Online

Registriert seit: 12. Aug 2003
Ort: Soest
4.017 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#16

AW: Sinn einfacher Getter und Setter

  Alt 19. Apr 2019, 14:51
Es geht aber nicht immer nur um Code Änderungen sondern auch möglicherweise um Binärkompatibilität.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
hzzm

Registriert seit: 8. Apr 2016
103 Beiträge
 
Delphi 10 Seattle Professional
 
#17

AW: Sinn einfacher Getter und Setter

  Alt 25. Apr 2019, 09:28
Get/Set scheint zunaechst unwichtig und kann auch trivial geloest werden.

Wenn Du Deine Programmstruktur allerdings feinfuehliger aufbaust und statt direkten uses Interfaces verwendest, die Du im idealfall dann mittels Constructor Injection oder DI-container bereitstellst, musst Du somit Getter/Setter verwenden.

Interfaces lassen diese direkten Feldvariablen nicht zu.

Zum Beispiel IAngestellter = Interface und TAngestellter = class(TInterfacedObject, IAngestellter) Deine Klasse TFirma braucht Feldvariable TAngestellter.FName, verwendet aber schlankerweise nicht uses Angestellter sondern FAngestellter: IAngestellter.
Das Interface FAngestellter laesst FAngestellter.Name aber nicht zu, sondern nur function FAngestellter.GetName: String;

Geändert von hzzm (25. Apr 2019 um 09:59 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 19:38 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