Get und Set

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

Get und Set

Beitrag von Mec24 (ForumUser / 2 / 0 / 0 ) »
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

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


Re: Get und Set

Beitrag von a-dead-trousers (Top Expert / 4259 / 211 / 1138 ) »
Deine Fragen haben ursächlich nichts mit ABAP zu tun. GET und SET Methoden gibt es in so ziemlich allen Programmiersprachen und gehören zum Grundwerkzeug von objektorientierter Programmierung.

Wenn es dir also nur um die Funktionsweise geht, such auf Google nach "get und set methoden". Und für ABAP Beispiele füge einfach "ABAP" hinzu.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Get und Set

Beitrag von msfox (Specialist / 302 / 50 / 62 ) »
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.

Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
urmel376


Re: Get und Set

Beitrag von Murdock (Specialist / 115 / 55 / 8 ) »
msfox hat geschrieben:
09.01.2024 21:32
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.
In ADT geht das über die "quick fixes" (STRG+1)

Re: Get und Set

Beitrag von DeathAndPain (Top Expert / 1792 / 213 / 392 ) »
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

Beitrag von ewx (Top Expert / 4771 / 294 / 626 ) »
DeathAndPain hat geschrieben:
23.01.2024 12:40
  • 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.
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! 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. Bestes Beispiel ist m.E.n. das Lesen von Informationen erst zu dem Zeitpunkt, an dem sie angefordert werden (durch Aufruf der Methode GET).
Ein anderes Beispiel ist, dass man intern die Verarbeitung komplett umstellen kann, ohne dass es Einfluss auf den Aufrufer hat.
DeathAndPain hat geschrieben:
23.01.2024 12:40
  • 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.
Das ist in der Tat so. OO Programmierung ist reich an Tücken, weil es viele Verknüpfungen gibt, die nicht direkt erkennbar sind. 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...

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers


Re: Get und Set

Beitrag von DeathAndPain (Top Expert / 1792 / 213 / 392 ) »
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

Beitrag von ewx (Top Expert / 4771 / 294 / 626 ) »
DeathAndPain hat geschrieben:
24.01.2024 19:13
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.
Was genau ist daran nachteilig? Du kannst ja trotzdem in die Methode reinsehen... Es wird nichts versteckt, es wird nur klar abgegrenzt.

Re: Get und Set

Beitrag von DeathAndPain (Top Expert / 1792 / 213 / 392 ) »
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

Beitrag von ewx (Top Expert / 4771 / 294 / 626 ) »
ich glaube, wir beide wollen uns einfach nicht verstehen.

Re: Get und Set

Beitrag von qyurryus (Specialist / 107 / 81 / 45 ) »
DAP vs Enno Boxing-Match um zu klären, wer Recht hat?

Re: Get und Set

Beitrag von ewx (Top Expert / 4771 / 294 / 626 ) »
Bild
Es geht ja gar nicht um richtig oder falsch. Es gibt viele Sichtweisen, Meinungen und Vorlieben. Ich habe nur das Gefühl, dass wir aneinander vorbei reden. So nach dem Motto:
- Schachmatt!
- Häh? Bei Halma gibt es doch gar keinen Elfmeter...

Re: Get und Set

Beitrag von DeathAndPain (Top Expert / 1792 / 213 / 392 ) »
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

Beitrag von ewx (Top Expert / 4771 / 294 / 626 ) »
Touché 😄

Oder auch:
wer will, findet Wege.
Wer nicht will, findet Ausreden. 🙃

Seite 1 von 1

Aktuelle Forenbeiträge

Länge von Datenelement
vor 2 Stunden von DeathAndPain gelöst 6 / 100
(Lange) Gedankenstriche in ABAP
vor 3 Stunden von MAJOR_TOM 8 / 94

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.

Aktuelle Forenbeiträge

Länge von Datenelement
vor 2 Stunden von DeathAndPain gelöst 6 / 100
(Lange) Gedankenstriche in ABAP
vor 3 Stunden von MAJOR_TOM 8 / 94

Unbeantwortete Forenbeiträge

Equipment ALE Integration
vor einer Woche von Prego 1 / 92