Modularisierung wie handhaben?

Re: Modularisierung wie handhaben?

Dele hat geschrieben:wovon SAP abrät, ist vollkommen irrelevant. Warum:
Und zum eigentlichen Thema:
Modulaisierung ist sehr zu empfehlen (In vielen SAP-Programmen wäre das sehr zu wünschen).
Aber eine pauschale Empfehlung, wo und wann bzw. ab wann, macht keinen Sinn. Das hängt zu sehr vom Kontext ab. Entscheidungskriterien könnten sein:
- Wiederverwendbarkeit (dann eher Methode oder Funktionsbaustein)
- Wahrscheinlichkeit der mehrfachen Nutzung
- Lesbarkeit eines Programmes
- und nicht zuletzt auch: einfacheres Testen (Debuggen)

gruß dele

Re: Modularisierung wie handhaben?

Re: Modularisierung wie handhaben?

Re: Modularisierung wie handhaben?

Re: Modularisierung wie handhaben?

Re: Modularisierung wie handhaben?

ewx hat geschrieben:Problem bei "externer Modularisierung" (Klassen, Funktionsbausteine, Includes) ist in der Regel: Wie weiß ich, dass ich danach suchen sollte? Wie weiß ich, wonach ich suchen könnte? Wie dokumentiere ich für andere, dass es diese Funktion gibt?

Re: Modularisierung wie handhaben?

bliss hat geschrieben:Nein, kenne ich gar nicht und konnte jetzt auf die schnelle auch keine Dokumentation dazu finden.

DEFINE fill_if_initial.
  if targetstruktur-&1 is initial.
    targetstruktur-&1 = sourcestruktur-&1.
  endif.
END-OF-DEFINITION.

fill_if_initial: feld1,
                 feld2,
*                 ...
                 feldn.

Re: Modularisierung wie handhaben?

Makros werden häufig wie aufrufbare Einheiten anstelle von echten Prozeduren benutzt. Dies ist jedoch nur in den wenigsten Fällen sinnvoll. Makros haben zum einen keinen eigenen Kontext, und zum anderen können sie nicht schrittweise im ABAP Debugger ausgeführt werden. Dies macht eine Fehlersuche in Programmen, die umfangreiche oder komplexe Makros verwenden, nahezu unmöglich. Aus diesen Gründen ist ein Makro kein vollwertiger Ersatz für eine echte Prozedur.

Darüber hinaus wurden Makros in der Vergangenheit nicht nur als Prozedurersatz, sondern unter anderem auch dazu verwendet, häufig wiederkehrende Deklarationen strukturierter Daten vorzunehmen. Heutzutage werden hierfür natürlich keine Makros, sondern eigenständige Typen verwendet.

In bestimmten Fällen kann der Einsatz von Makros dennoch gerechtfertigt sein, und zwar dann, wenn einfache, wiederkehrende Anweisungsmuster vorliegen. Ein Makro kann hier als Mittel zur Designzeit-Generierung angesehen werden. Das folgende gute Beispiel zeigt eine solche Verwendung eines Makros. In einem solchen Fall kann der Einsatz eines Makros aus folgenden Gründen die bessere Lösung als die Verwendung einer Prozedur sein:

• Die im Makro enthaltene Anweisungsfolge ist hinreichend einfach und offensichtlich, sodass die fehlende Möglichkeit des Debuggens nicht ins Gewicht fällt.
• Die Anweisungen werden statisch von der Syntaxprüfung auf Korrektheit hin überprüft. Beim Einsatz der sonst notwendigen dynamischen Sprachmittel in einer Prozedur würden Fehler (in diesem Beispiel falsch angegebene Bezeichner) erst zur Laufzeit entdeckt werden. Darüber hinaus wäre der dynamische Zugriff zeitaufwendiger.
• Gegenüber der Ausformulierung aller Einzelanweisungen bleibt der Quelltext beim Einsatz solcher Makros übersichtlicher, insbesondere bei einer hohen Anzahl von Wiederholungen der Anweisungsfolge. Die Gefahr von trivialen Schreibfehlern sinkt, da weniger sich stark ähnelnder Quelltext erstellt und gepflegt werden muss. Änderungen an der Logik sind im Nachhinein mit geringerem Aufwand möglich.

In bestimmten Fällen kann der Einsatz von Makros die Korrektheit und Wartbarkeit von Quelltext also erhöhen. Makros, die nicht triviale Kontrollstrukturen enthalten, stellen aber stets ein Wartungsproblem dar, da sie nicht schrittweise vom ABAP Debugger ausgeführt werden können. Wenn daher Makros verwendet werden, sollte dies äußerst sparsam geschehen, und sie sollten nur wenige Zeilen umfassen, da Fehler in Makros kaum zu analysieren sind.