Get und Set

Get und Set

Hallo,

ich beginne jetzt ABAO OO zu lernen und habe eine Frage bezüglich der Get und Set Methoden.

Können Sie mir vielleicht mit Beispielen erklären worum genau es geht?

Nach der Definition einer Get bzw. Set Methode wie kann ich die implementieren und danach ausgeben?

was ist genau der Ziel dieser Methoden?

Ich freue mich schon auf Hilfe und bedanke mich bei Ihnen.

LG

Frank

Re: Get und Set

Rein technisch sind die GET-/SETter-Methode im einfachsten Fall dafür da, um auf Attribute in der Klasse zugreifen zu können -i.d.R. auf private oder protected Attribute. Somit kannst du z.B. auch steuern, wenn du mit Vererbung arbeitest, welches Attribute von welcher Klasse geliefert wird. Auch mach es in Inferfaces Sinn, wenn das Interface immer bestimmte Werte liefert soll. Wo die dann aus der Klasse erkommen und wie sie dort gehalten werden, ist für den Aufrufer unwichtig. Genau so etwas könnte man z.B. nicht machen, wenn man die Attribute public definiert und fest darauf zugreife. Ok, man kann auch Interface public-Attribute definieren....
In Eclipse bei Java gibt es z.B. im Context-Menü die Möglichkeit, sich für die Attribute der Klasse einfach die GETTER und SETTER generieren zu lassen. Das vermisse ich in der SE80 immer. Ich habe allerdings noch nicht probiert, ob das auch über Eclipse für ABAP geht.

Re: Get und Set

Um es auf den Punkt zu bringen:

• Attribute sind die globalen Variablen einer Klasse. Sie haben dieselben Nachteile wie globale Variablen alter, nicht objektorientierter Sprachen (einschließlich ABAP ohne OO). Die vorherrschende Ideologie besagt aber, dass globale Variablen alter Schule schlecht sind, weil sie das Programm schwer verständlich und schlecht wartbar machen, diese neue Form globaler Variablen aber gut sei, obgleich sie dieselben Nachteile mit sich bringt.
• Es ist üblich, Attribute mit einer SET-Methode zu verändern und mit einer GET-Methode wieder aus dem Objekt auszulesen. Dadurch kann man das Attribut in den privaten Bereich der Klasse packen, so dass es von außen nicht zugänglich ist. Man erhält eine Information, die im Objekt versteckt ist mit der Folge, dass die Methoden des Objektes sich unterschiedlich verhalten können, wenn sie mit denselben Parametern aufgerufen werden, je nachdem, welche zusätzlichen Informationen in den privaten Attributen des Objektes versteckt sind und von der Methode genutzt werden. Damit wird eine saubere Schnittstellenkapselung in meinen Augen konterkariert. Die Technik erinnert sehr an das Verstecken von Informationen im ABAP Memory, was dann von anderen Programmen und Unterroutinen ausgelesen wird und wo nachher auch keiner mehr nachvollziehen kann, wie das alles zusammenhängt und wo die Werte herkommen, mit denen plötzlich gearbeitet wird.
• Verstehen und warten kann man solch Objekt daher nur, wenn man die Funktionen der in der Klasse enthaltenen Atribute genau kennt und verstanden hat. Damit das Ganze wartbar ist, müssten diese daher penibel und gut verständlich dokumentiert werden und das an einer Stelle, die jeder wiederfindet (vorzugsweise also direkt online in der Klassendokumentation). Da dies aber in der Realität niemand macht, sind OO-Programme, die richtig mit Objekten arbeiten, oft extrem schwer zu verstehen und für Leute, die sie nicht programmiert haben, sehr schwer (teils unmöglich) zu warten.

Re: Get und Set

ewx hat geschrieben: ↑

23.01.2024 14:53

In dem Fall geht es ja auch tatsächlich ums "Verstecken". Oder man könnte auch sagen: Kapseln. Die Schnittstelle der Methode ändert sich ja nicht!

Richtig. Und das ist ein Nachteil und nichts anderes, auch wenn OO-Apologeten gerne etwas anderes behaupten.

Und das bietet der Klasse genau die Möglichkeit, die man mit direktem Zugriff auf Variablen nicht hat, nämlich selbst entscheiden zu können, wie die Daten verwaltet und nach außen gegeben werden.

So dass man sich mit dieser Heimlichtuerei (vor anderen, die den Code später verstehen oder gar warten sollen) jede Menge Probleme schaffen kann, nur um sich selber auf die Schulter klopfen zu können, wie modern man doch programmiere.

Dafür gibt es jedoch Konzepte, die man lernen kann und sollte (Design pattern). Es ist einigermaßen ungerecht, die klassische ABAP-Programmierung mit OO zu vergleichen und zu sagen: ohne OO war es leichter. Motoren waren früher auch einfacher zu warten. Das heißt aber nicht, dass ich wieder einen Käfer-Motor von 1970 in meinem Auto haben möchte...

Weil die heutigen Motoren deutlich leistungsfähiger sind. Das sehe ich aber im Bereich der Klassenattribute nicht; die schaffen nur Nachteile. Die von Dir genannten "Vorteile" halte ich für rein ideologischer Natur: Da hat irgendein Professor gesagt, sowas sei gut, also halten es alle für gut. In der Praxis haben wir dadurch Programme, die viel schlechter zu warten sind.

Nach meiner praktischen Erfahrung gibt es im Bereich von OO nur einen echten Fortschritt, der sich nicht mit prozedural gebauten Programmen gleichwertig nachstellen lässt, und das ist die Vererbung. Wenn man Programme baut so wie z.B. Ralf hier das macht, dann hat das sicherlich seine Daseinsberechtigung. Nach allem, was ich bisher gesehen habe, wird Vererbung in der Praxis aber nur sehr selten verwendet. Häufig hingegen sieht man "objektorientierte" Programme, bei denen zu Programmbeginn ein einziges Objekt erzeugt wird, in dem dann das Programm läuft. Sowas hat mit OO aber nicht wirklich was zu tun. Ich bin der Meinung, dass man immer dann, wenn man nicht wirklich mit unterscheidbaren Objekten arbeiten möchte, dies im Code deutlich machen sollte, indem man statische Klassen verwendet. Dadurch fällt eine bedeutsame Abstraktionsebene weg, die keine Punkte bringt, wenn nicht mehr als ein Objekt im Spiel ist. Das Programm wird deutlich besser verständlich, und man spart sich Overheads wie Konstruktormethoden und Datendeklarationen für die Objekte.

Die Syntax von OO ist den alten Konstrukten wie FORM-Routinen und Funktionsbausteinen überlegen, jedenfalls bei den Aufrufen (und die sind der Teil, auf den es ankommt, wenn es um Verständlichkeit des Codes geht). Daher verwende ich auch nur noch die neuen Konstrukte, auch wenn ich immer noch der Meinung bin, dass die Trennung in Definition- und Implementation-Block ein unnötiger Wasserkopf ist, den sich irgendwelche Universitätsprofessoren ohne Praxisbezug ausgedacht haben.

Re: Get und Set

Ja, und in der Methode siehst Du dann, dass der Feldwert von gv_geheimzahl in einer Weise verwendet wird, die Dir nicht klar ist (weil der Code nicht von Dir ist oder weil Du das vor zwei Jahren programmiert hast und seitdem nicht mehr dran warst). Du würdest gerne ergünden, welche Information er beinhaltet. Dazu wäre es wichtig zu wissen, wo der darin enthaltene Wert herkommt. Weißt Du aber nicht. Der ist irgendwann mal gefüllt worden, von irgend einer anderen Methode (oder von der SETter-Methode, die von irgendeiner anderen Methode aufgerufen wurde, was auf dasselbe hinausläuft). Genau das klassische Problem globaler Variablen.

Wäre iv_geheimzahl Teil der Methodenschnittstelle, dann hättest Du eine saubere Kapselung mit einer sich deterministisch verhaltenden Methode, die man für sich betrachten kann. Dann könnte man im Debugger oder SE38 auch sauber verfolgen, wo der Wert herkommt. Das Versteckspiel bringt nur Nachteile.

Vor allem: Wenn die Methode nicht das tut, was sie tun soll, dann weißt Du nicht, ob der Bug in der Methode liegt, die Methode also nicht richtig funktioniert oder ob der Bug dort liegt, wo der Wert in gv_geheimzahl versteckt worden ist, so dass die korrekt programmierte Methode mit einem falschen Wert arbeitet und nur deshalb nicht zum richtigen Ergebnis kommt. Wäre iv_geheimzahl Teil der Methodenschnittstelle, dann könntest Du die Methode isoliert betrachten und sofort erkennen, ob sie in Abhängigkeit des übergebenen Wertes korrekte Ergebnisse bringt oder nicht.

Re: Get und Set

DAP vs Enno Boxing-Match um zu klären, wer Recht hat?

Re: Get und Set

Für Deinen Vergleich von Klasenattributen vs voll parametrisierten Methodenschnittstellen mit alten vs neuen Autos habe ich jetzt aber ein gutes neues Argument gefunden. Im Lichte dieses aktuellen Artikels kann ich Deinen Vergleich voll akzeptieren. 😁

https://heise.de/-9599141

Re: Get und Set

Ich hab den Thread gerade erst gesehen und möchte hinzufügen, dass SETTER und GETTER inzwischen sehr unüblich sind im OO. Der Zustand "gelesen" des Objekts "eBook" kann von mehreren Attributen abhängen und die müssen dann auch per Methode zusammen geändert / gelesen werden -- damit der Verwender des Objektes gar nicht erst wissen muss, wie die internen Attribute sich zu Zuständen verknüpfen.

Also schreibe keine SETTER und GETTER, sondern schreibe Methoden, die konsistente Zustände erzeugen oder auslesen.

Insofern ist schon die Frage kritikwürdig.


Ralf