Get und Set

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
18 Beiträge • Vorherige Seite 2 von 2 (current)
18 Beiträge Vorherige Seite 2 von 2 (current)

Re: Get und Set

Beitrag von tar (ForumUser / 90 / 22 / 28 ) »
Ist denn ein Node.HasChild() etwas anderes als ein Getter? 😉

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Get und Set

Beitrag von msfox (Specialist / 364 / 56 / 74 ) »
ralf.wenzel hat geschrieben:
17.10.2024 11:57
Also schreibe keine SETTER und GETTER, sondern schreibe Methoden, die konsistente Zustände erzeugen oder auslesen.
Jain. Wenn auf konkrete Daten der Klasse zugreifen will - z.B. Name, Vorname um dies ggf. auf einer Maske darzustellen, brauche ich dafür GETTER. Um die Eingabe von der Maske wieder in das Objekt zu bekommen, bedarf es SETTER.

Code: Alles auswählen.

Ist denn ein Node.HasChild() etwas anderes als ein Getter? 
Kommt drauf an.
Wenn man eine konkreten Wert/Attribute aus der Klasse abfragt, wäre es ein GETTER. Müsste dann aber gethasChild() heißen.
In dem Fall gibt es aber vermutlich eine Tabelle mit Kind-Knoten. Dabei prüft man, ob diese Tabelle gefüllt ist oder nicht und gibt das Ergebnis zurück. Anders wäre Node.getChilds(). Wäre ein Getter, weil man sich einfach die Tabelle gebe lässt.
--
Die quick-Fixes in Eclipse wurden ja schon angesprochen. Aus JAVA kenne ich das, dass man Attribute definiert und sich dann mit via quick-Fix die GETTER und SETTER generieren lässt. Da ist dann keine Logik in den Methoden, außer die Rückgabe genau dieser Attributwerte.

Re: Get und Set

Beitrag von tar (ForumUser / 90 / 22 / 28 ) »
Rate mal, wieso ich gerade dieses Beispiel wählte: eben weil man 1. keine konkreten Kindknoten haben möchte und 2. nicht nach jedem Aufruf nochmal selbst die Rückgabe etwaiger Kindknoten prüfen möchte, sondern 3. lediglich die Info braucht, ob es überhaupt Kindknoten gibt und man 4. diese Info ohne weitere außerhalb der Klasse liegende Prüfungen direkt haben und wahrscheinlich auch unmittelbar als Boolean und somit als fertig vorliegende Bedingung (für IF usw.) nutzen möchte.

Klassenintern wird dabei natürlich ein (hoffentlich) vorliegendes Attribut abgefragt, nämlich ob der Tree der Kindknoten leer ist. Das Attribut selbst wird aber nicht ausgegeben.

Ist das nun kein Getter, weil man dafür nicht parallel ein weiteres Klassenattribut vorhält? Nein - weil die Klassenattribute selbst nichts anderes als derartige Methoden sind, nur eben stark vereinfacht bzw. zum besseren Verständnis umgekehrt: derartige Methoden nichts anderes als vorliegende Eigenschaften von Klassen zurückgeben (die daher nicht zwingend als einzelnes Attribut vorliegen müssen). Von außen betrachtet ist eine derartige Methode aber identisch zu einem Attribut: man erhält (GETTED) letztlich eine Klasseneigenschaft.

Ganz grundsätzlich gibt es auch für Getter- & Setter-Methoden, die einzig und allein dazu dienen, einzelne Klassenattribute direkt auszulesen oder zu setzen, keinerlei Daseinsberechtigung:
- braucht man beides, kann und sollte man direkt auf die Klassenattribute zugreifen
- möchte man das Schreiben von außerhalb verhindern, kann man dies mittels read-only tun

Daher nutzt man Getter- & Setter genau dann, wenn man
- keine entsprechenden Klassenattribute vorhält
- sich mehrere Eigenschaften (ggf. auch weitere, davon abhängige Objekte) auf einmal ändern, bspw. sich bei Customer.UpdateAddress(newAddress) Straße, Hausnr. etc. ändern und bei einem Umzug ins Ausland die für ihn genutzte Korrespondenzsprache, Versandwege, Steuersätze, usw. usf.
- man komplexe Zugriffe auf Klassenattribute nach außen vereinfachen möchte, bspw. eben bei Node.HasChild() nicht erst noch zusätzlich prüfen will, ob das Attribut ChildNodes gefüllt ist oder man mittels ALV.SetEditable() nicht alle Spalten einzeln auf eingabebereit stellen will, usw. usf.
- generell zusätzliche Logiken nutzt

So nutze ich mitunter eine relativ simple Methode, die dennoch über die reine Abfrage eines Attributs hinaus geht, indem zunächst geprüft wird, ob das zugehörige Attribut initial ist. In diesem Fall wird es von der Datenbank gelesen (oder aus einem anderen Attribut, einer anderen Methode oder woher auch immer ermittelt), gesetzt und erst dann zurückgegeben. Beim nächsten Aufruf verhält sich die Methode wie ein einfacher Getter, da das Attribut ja nun nicht mehr initial ist. Das ist eine Art "only-on-explicit-demand"-Getter zur Performanceverbesserung und diese muss je nach Konstrukt auch nicht zwingend public sein.


Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.