Deklaration von Variablen

[DeathAndPain]

Quatsch, ich reiße Leuten höchstens den Kopf ab, wenn sie für mich programmieren und dabei Murks machen.

Friss mal schön Kreide, glaubt Dir hier eh keiner.

Und warum ein privates Attribut einfach eine globale Variable sein soll, erschließt sich mir nicht. Ich habe den Eindruck, du weißt gar nicht, warum man Attribute als protected oder private deklariert. Das hat was mit Objektkonsistenz zu tun.

Doch, ich weiß das schon. Nur in dem Moment, in dem es nicht mehr public ist, erfüllt es noch nicht mal mehr den Zweck, eine von außen sichtbare Objekteingeschaft zu sein. Von innerhalb der Klasse ist es immer sichtbar, aber innerhalb der Klasse ist die Eigenschaft, ein "Attribut" zu sein, nicht mehr als ein netter Name. Es ist ein (klassen-)globales Feld, das einen Wert enthält. Genau wie jede andere globale Variable auch. Insbesondere ist es gut mit den globalen Variablen von Funktionsgruppen vergleichbar. Es ist wahr: Funktionsgruppen können nur statische Klassen modellieren. Das aber tun sie recht gut.

Ich arbeite fast nie mit öffentlichen Attributen, damit das Objekt kontrollieren kann, ob es sich überhaupt um einen gültigen Wert handelt.

In meinen Augen ist das gleich der nächste Pfusch bei der Umsetzung der OO-Idee. Unabhängig von ihrer Sichtbarkeit müssten alle Objektattribute für jegliches Coding außerhalb der Klasse auf Read-Only stehen. Dann wäre es auch nicht dramatisch, wenn externes Coding das Attribut "sehen" kann. Es gibt auch viele Funktionsbausteine und Methoden, um irgendwelche Werte zu beschaffen, doch häufig ist es performanter, diese Werte einfach selber von der Datenbank zu selektieren. Jeder macht das, und keiner hat ein Problem. Nur bei Objekten muss Verstecken gespielt werden. Aber von mir aus soll OO diese Spielwiese haben; PRIVATE und PROTECTED richten ja keinen Schaden an. Dass öffentliche Objektattribute aber von externem Code manipuliert werden können, macht keinen Sinn. Du räumst ja gerade selber ein, dass dieser Umstand öffentliche Attribute nahezu unbrauchbar macht und man als Workaround über umständliche und performancefressende Getter-Routinen gehen muss.

Bis dahin: Ja.
Nur ist das Feldsymbol von da an für den Rest des Programms
(in der Reihenfolge des Codings) gültig. Das ist Murks.
Verwendet man es wieder (weil man die Tabelle öfter braucht)
ist es eimal inline und x-mal extern definiert. So liebe ich das .
Und wehe wenn jetzt jemand eine Routine oder ein Include
umhängt. Wer das erfunden hat gehört gesteinigt!
Richtig gemacht wäre es wenn das Feldsymbol nur während des
Loops gültig ist.

Das wäre optimal, bin ich Deiner Meinung. Aber ich habe ja betont, dass man es in der Praxis nur so verwenden sollte, als ob es so wäre.

[ralf.wenzel]

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

[black_adept]

Bis dahin: Ja.
Nur ist das Feldsymbol von da an für den Rest des Programms(in der Reihenfolge des Codings) gültig.

Nicht bis zum Ende des Programms sondern bis zum Ende der Modularisierungseinheit. Nur wenn es global erzeugt wird ist es auch im gesamten Code gültig.
Und das durch inline-Deklaration erzeugte Feld ist danach dann auch vor der Aufrufstelle verfügbar ( wenn man z.b. in einer Schleife ist! ) - aber davon rät SAP ja aus gutem Grund explizit ab das zu tun und man muss auch tricksen um da ran zu kommen.

[Sebastian82]

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!

[msfox]

Eine Funktionsgruppe ist schon deshalb nicht eine Klasse, weil ihr entscheidende Eigenschaften fehlen, die eine Klasse per Definition hat. Wahr ist: Beides sind Programm-Module. Aber eine Funktionsgruppe beschreibt kein Geschäftsobjekt (z. B. einen Beleg), das kann sie auch gar nicht, weil ich sie nicht instanziieren kann.

Ich wollte Klasse und Funktionsgruppe nicht gleichsetzen - auf keinen Fall, nur Parallelen ziehen.
Wenn das gleich wäre, hätte man in ABAP nicht OO eingeführt und man bräuchte sich in der Fremdenpflege des BDT nicht den Finger in der Nase brechen.
Instanzen zu unterschiedlichen Anwendungsobjekten kann man ja noch erzeugen. Wobei sich die SAP hier mit "Stack-Tabellen" für die Werte jeder Instanz rettet.
Aber zwei Instanzen z.B. vom BUPA schon nicht mehr. Weil es nun mal nur ein Memory für den BUPA gibt. Mit ABAP OO wäre dies kein Problem.

[DeathAndPain]

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

Vielen Dank, das reicht mir völlig.