Deklaration von Variablen

Re: Deklaration von Variablen

Zu den Inline-Deklarationen ist zu sagen, dass die mit Blick auf OO entstanden sind. Methoden im OO sind im Allgeneinen sehr kurz (jede Methode tut genau EINE Sache, ich kenne nicht wenige, die sagen: „Eine Methode, in der ich scrollen muss, ist zu lang“).

Dann kann man auch Coding schreiben, das man versteht, wenn man keinen einzigen ABAP-Befehl kennt, weil die Namen der Methoden quasi die Aufgabe von Kommentaren übernehmen. Wenn man das so macht, verlieren auch Mehrfach-Verkettungen ihren Schrecken, weil sie sehr sprechend sein können.

Und DANN stört auch kaum, dass eine inline deklarierte Variable eben methodenweit gültig ist.

Zu dem anderen Thema:

Der Unterschied zwischen einer Funktionsgruppe und einer Klasse ist übrigens auch, dass ich ein Objekt (bestehend aus seinem Zustand UND seinem Coding) an ein anderes übergeben kann. Ich verweise hier zum 5. Mal auf mein Beispiel mit den ALV-Buttons, die als Klassen realisiert werden. Der Eventhandler (oder der Dialog) kann der Applikation quasi den Button übergeben, weil er (wie alle anderen Buttons) ein bestimmtes Interface implementiert. Weder der Dialog noch das Programm müssen wissen, welche Funktion der Button ausführt. Wenn ein neuer Button hinzukommt, subscribe ich ihn an die Toolbar und muss weder Dialog noch Applikation ändern und testen.

Diese Form der verborgenen, weil in sich geschlossenen und autarken Implementierung ist kein Versteckspiel, sondern das Wesen der Kapselung. Nach dem Motto „das Ding sorgt für sich selbst“ In unserem Projekt können wir aus einer Vielzahl von Geschäftsobjekten sehr schnell neue Applikationen bauen, weil das Verhalten eines Geschäftsobjektes sich ja nicht ändert und es selbst für seine Konsistenz sorgt.

Beispiel: Wir arbeiten viel mit Arbeitsvorräten. Die sind so generisch gestaltet, dass wir die (obwohl eigentlich für den Kunden) gedacht, bereits für Entwickler einsetzen. Ein Arbeitsvorrat ist immer grundsätzlich gleich, sie unterscheiden sich im Wesentlichen durch die Objekte, die sie verwalten. Da ist dem AV echt egal, ob das ein Genehmigungsprozess für eine Blutprobe ist oder die anstehende Eingabe manueller Messwerte oder eine Liste von noch zu dokumentierenden Klassen.

Das geht deshalb, weil der AV selbst gar nicht weiß, WAS er da verwaltet. Und WIE ein Objekt verwaltet werden muss, weiß es selbst. So übergibt man dem AV eine Liste von Objekten, denen er auf Benutzerkommando nur sagt „mach mal deinen nächsten Schritt“, ohne zu wissen, wie der aussieht. Das weiß das Objekt selbst, weil es seinen Status kennt (aus der ganz normalen SAP-Statusverwaltung) und weiß, welcher Schritt dem aktuellen Status folgt. Eben weil ein Objekt nicht nur Daten, sondern sein Verhalten (Coding) mitbringt. Dann wird aus einer „dummen Setter-Methode“ sehr schnell eine, die den nächsten Schritt im Arbeitsvorrat auslöst, workflows anwirft und komplexe Dinge macht, weil sich ein Wert ändert. Das wiederum geht nur, wenn ich den Wert selbst verstecke und so die Änderung über eine Setter-Methode erzwinge.

Ebenso die Trennung von Dialog und Funktion: Bei einem Programm fiel auf, dass der Dialog (freundlich gesagt) an den Bedürfnissen des Anwenders vorbeiprogrammiert wurde. Die Funktion selbst war aber völlig OK, so konnten wir einen neuen Dialog schreiben, ohne die Funktion des Programms sich nur anzufassen. Weil die Applikation gar nicht weiß, von welchem Dialog sie gesteuert wird. Technisch gesprochen: Ein Dialog meldet sich als Observer bei der Applikation an, somit meldet die Applikation jede Statusänderung (bitte nicht verwechseln mit der SAP-Statusverwaltung, hier geht es um den rein transienten Status der Applikation) an die Observer (das können auch übergeordnete Applikationen oder Schnittstellen sein), was der Dialog daraus macht, weiß die Applikation gar nicht. Darum ist MESSAGE außerhalb des Dialoges bei uns verboten, weil das eine reine Dialoganweisung ist, die genau diese Kapselung kaputtmachen würde. Die Applikation sammelt Meldungen im Applog und wenn der Status der Applikation (z. B. „Buchung durchgeführt“ oder „Fehler bei der Buchung“) für den Dialog ein Grund ist, das Applog anzuzeigen, dann tut er das. Eigenständig. Und sogar in unterschiedlichen Detaillierungsgraden abh. davon, ob wer aus der Fachabteilung vor dem Rechner sitzt oder ein Entwickler (der technische Fehlermeldung braucht, mit denen ein Anwender kaum was anfangen kann).

Und zu statischen Klassen: Ich weiß nicht, wann ich meine letzte statische Klasse geschrieben habe. Muss ewig her sein. Der Funktionsumfang ist mir einfach zu klein.


Ralf

Re: Deklaration von Variablen

Wie es aussieht ist es zum Teil wohl wirklich historisch bedingt. Ich kannte das schon von Delphi. Da gab es sowas auch.
Und auf einen Teil der Antworten konnte ich mir noch keinen Reim machen. Dafür stecke ich noch nicht tief genug in ABAP drin

Danke jedenfalls für eure Antworten!

Re: Deklaration von Variablen

Ich wollte Klasse und Funktionsgruppe nicht gleichsetzen - auf keinen Fall, nur Parallelen ziehen.

Vielen Dank, das reicht mir völlig.