Warum man Separation of Concerns (immer noch) so gut es geht befolgen sollte

Separation of Concerns ist wirklich nicht neu und geht ins Jahr 1974 zurück. Dabei ist es bis heute eines der fundamentalsten Prinzipien der Softwareentwicklung. Gerade in der SAP-, bzw. klassischen ABAP-Welt allerdings nicht immer wirklich gelebt, obwohl es nicht wirklich schwer zu verstehen ist. Die Vorteile dieses Prinzipes werden aber wieder stärker wiegen gerade aufgrund der wachsenden Wichtigkeit von TDD.

Das Prinzip besagt so wenigen durchgängige und verwobenen Code wie möglich zu schreiben und diesen stattdessen in getrennte Einheiten zu zerlegen. Diese Einheiten sollten so gut es geht unabhängig voneinander sein. Die Klassiker um dies zu erreichen sind Modularisierung und Kapselung.

Grundsätzlich bietet der SAP NetWeaver Application Server ABAP durch die 3-Schichtenarchitektur sicher schon lange zumindest teilweise nicht die schlechtesten Voraussetzungen dafür. Und ein noch viel größerer Vorteil? ABAP Objects. Ebendieses ermöglicht nämlich mit einem gewissen objektorientierten Grundverständnis sehr einfach auf Anwendungsebene Modularisierung und Kapselung zu erreichen.

ABAP Objects in Kombination mit SoC hat schon zwei große Vorteile, nämlich Wiederverwendbarkeit und Nachvollziehbarkeit, bzw. gute Lesbarkeit. Vorausgesetzt man baut seine Anwendung dementsprechend auf. Gerade mit wachsender Komplexität wird das Ganze auch besser wartbar. Und auch besser testbar. Kapselt man zum Beispiel Datenbankzugriffe(Persistenz) oder Zugriffe auf externe Schnittstellen sind diese einfach zu mocken.

Genauso sollte man das User Interface von der Persistenz trennen. Gerade bei größeren Anwendungen macht es daher Sinn sich das Paketkonzept zu nutze zu machen und mit entsprechenden Paketschnittstellen und Paketprüfungen zu arbeiten. Dadurch kann man auch bei komplexeren Anwendungen sicher sein, dass SoC entsprechend eingehalten wird.

Viele SAP-Programmiertechniken, bzw. Programmiermodelle unterstützen schon von Hause aus die Einhaltung des SoC. Damals schon Web Dynpro oder der Floorplanmanager, über das Fiori Programmiermodell bis hin zu neuen Programmiermodellen wie dem ABAP RESTful Application Programming Model.

Doch in der Praxis bietet sich auch oft noch ein weiteres Bild. So bestehen die Probleme oft bei der Masse an kleinen und mittelgroßen Anwendungen. Bei großen Anwendungen macht man sich meist eher Gedanken um eine sinnvolle Archictektur. Deshalb gilt auch bei kleinen Reports versuchen so gut es geht auf SoC zu achten. 🙂