SOLID Principles in der SAP-Welt: So gelingt zukunftssichere ABAP-Entwicklung auch unter S/4HANA
Lesezeit: 6 Min
Clean Code ist für viele Programmierer:innen eines der wichtigsten Gebote. Warum? Ein sauberer Code ermöglicht nicht nur eine bessere Übersicht, mehr Flexibilität und eine einfache Wartung – on top fördert er die Zusammenarbeit, indem er den Code für alle Teammitglieder leicht verständlich macht. Dieses Prinzip ist besonders relevant in einer sich schnell entwickelnden Umgebung wie der ABAP-Entwicklung.
Während traditionelle, oft prozedurale und monolithische ABAP-Lösungen lange Zeit akzeptabel waren, stoßen sie in der neuen Welt von S/4HANA und Cloud-Entwicklung mit kontinuierlichen Updates zunehmend an ihre Grenzen. Lange Zeit galten Formroutinen, Funktionsbausteine und globale Daten als „good enough“. Die Anforderungen an Flexibilität, Wartbarkeit und Erweiterbarkeit haben sich allerdings drastisch geändert.
Genau hier kommen die SOLID Principles ins Spiel. Als bewährtes Konzept aus der objektorientierten Programmierung helfen sie, robusten, wartbaren und flexiblen Code zu schreiben – und sind damit perfekt für die Herausforderungen von heute – die SOLID-Prinzipien helfen uns dabei:
- besseren Code zu schreiben
- leicht verständliches Software-Design aufzubauen
- vorhandenen Code einfach zu pflegen und leicht zu erweitern
SOLID ist nicht nur ein Schlagwort, sondern ein fundamentaler Baustein für die Clean-Code–Philosophie und eine technische Voraussetzung für eine erfolgreiche Clean-Core-Strategie.
Begriffsdefinitionen:
- Solid Principles: Die SOLID Principles wurden von Robert C. Martin eingeführt und bieten einen Leitfaden für besseres Softwaredesign. Sie sind leicht zu erlernen, aber schwer zu meistern, bilden aber das Fundament für eine zukunftssichere Entwicklung.
- Clean Code: Eine Philosophie, die zu lesbarem, verständlicherem, wartbarerem und wiederverwendbarem Code führt.
- Clean Core: Das Hauptziel ist die Entkopplung von kundeneigenen Erweiterungen vom SAP-Standard. Dadurch soll die Stabilität bei Upgrades gewährleistet werden.
But first: Was ist überhaupt ein Prinzip in der Softwareentwicklung?
Prinzipien sind grundlegende Regeln und Gesetze, die bei der Softwareentwicklung immer einzuhalten sind – man könnte sie mit der einfachsten Matheregel “Punkt vor Strich” vergleichen. Anders gesagt: Sie sind dazu da, um Probleme zu lösen oder zu vereinfachen. Außerdem helfen sie Ihnen und Ihrem Team dabei, dass die resultierende Software bestimmte Eigenschaften wie Wartbarkeit, Flexibilität oder Wiederverwendbarkeit besitzt. Diese Eigenschaften sind abhängig vom jeweiligen Prinzip.
Was bedeuten die SOLID Principles ausgeschrieben?
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Die SOLID Principles im SAP-Kontext erklärt
Die SOLID Principles sind mehr als nur ein theoretisches Konzept der objektorientierten Programmierung – im SAP-Kontext sind sie der Schlüssel zur Entwicklung von robusten und wiederverwendbaren ABAP-Lösungen, die den Grundstein für eine nachhaltige Clean-Core-Strategie legen.
Single Responsibility Principle
Dieses Prinzip besagt, dass eine Klasse nur eine einzige Verantwortung haben sollte, sodass es auch nur einen Grund gibt, sie zu ändern.
Statt einen riesigen Funktionsbaustein zu erstellen, der alles erledigt – vom Lesen der Daten über die Transformation, der Anzeige in einem ALV-Grid bis hin zum Versenden von E-Mails – sollte beim Single Responsibility Principle die Logik aufgeteilt werden.
Sinnvoller ist es, spezialisierte Klassen zu schaffen: eine für den reinen Datenbankzugriff, eine weitere für die Mailversand und eine dritte für die Verarbeitung von Daten, eine für die Anzeige, usw. Ein übergeordneter Controller kann diese kleinen, fokussierten Klassen dann orchestrieren, was die Wartung und Testbarkeit enorm verbessert.
Vorteile des Single Responsibility Principle:
- Einfache Wartung: Da man für jede Klasse einen klaren Zweck definiert, ist diese einfacher zu warten, weil sie kleiner und übersichtlicher ist
- Vermeidung von Seiteneffekten in Bezug auf andere Verantwortlichkeiten bei Änderungen
- Bessere Zusammenarbeit: Die Arbeit in Programmierteams kann besser aufgeteilt werden, denn jeder Programmierende kann dann an einer Klasse arbeiten, für die er/sie zuständig ist.
- Hält Abhängigkeiten bei der Wiederverwendung von Klassen auf ein Minimum
- Durch kleine Klassen wird die Fehlerbehebung stark vereinfacht
- Möglichkeit, klare und aussagekräftige Klassennamen zu vergeben, da jede Klasse eine Verantwortung hat
- Entkopplung von Implementierungen auf der Grundlage dessen, was sich wahrscheinlich gemeinsam ändern wird
- Aufwand für Entwicklung und Tests wird gesenkt
Open Closed Principle
Beim Open Closed Priciple sollten Software-Einheiten offen für Erweiterungen, aber für Modifikationen geschlossen sein.
Ein typisches Anti-Beispiel ist eine lange IF- oder CASE-Anweisung, die verschiedene Abwesenheitsarten wie Krankheit oder Urlaub unterscheidet. Kommt eine neue Abwesenheitsart hinzu, muss der bestehende, getestete Code geändert werden.
Besser ist es, ein allgemeines Interface für die Behandlung von Abwesenheiten zu definieren. Für jede Abwesenheitsart wird dann eine eigene Klasse erstellt, die dieses Interface implementiert. Eine Factory-Klasse kann die passende Implementierung zur Laufzeit auswählen, sodass für neue Abwesenheitsarten lediglich eine neue Klasse hinzugefügt werden muss, ohne den alten Code anzufassen.
Vorteile des Open Closed Principle:
- Fehler werden vermieden, da bereits geschriebener Code in Ruhe gelassen wird
- Software wird wartbarer
- Wiederverwendung durch den Entwurf stabiler Schnittstellen
Liskov Substitution Principle
Nach dem Liskov Substitution Principle muss eine abgeleitete Klasse ihre Basisklasse jederzeit ersetzen können, ohne Fehler zu verursachen. Das bedeutet, eine Unterklasse muss sich immer so verhalten, wie es die Oberklasse vorgibt.
Stellt man sich eine Basisklasse Mitarbeiter mit einer Methode zur Bonusberechnung vor, so müssen alle abgeleiteten Klassen – wie Vertriebsmitarbeiter, Consultant oder Entwickler – diese Methode so implementieren, dass sie ein sinnvolles Ergebnis liefert. Der aufrufende Code kann dann mit einer Liste von Mitarbeiter-Objekten arbeiten und darauf vertrauen, dass jede Bonusberechnung funktioniert, egal welcher konkrete Mitarbeitertyp dahintersteckt.
Vorteil des Liskov Substitution Principle:
Sicherheit, dass eine Implementierung ausgetauscht werden kann, ohne ihr Verhalten zu ändern
Interface Segregation Principle
Dem Interface Segregation Principle zufolge sollte keine Klasse gezwungen sein, von Methoden abhängig zu sein, die sie nicht verwendet. Anstatt ein riesiges „Gott-Interface“ mit 50 Methoden für den gesamten HR-Bereich zu schaffen, ist es besser, viele kleine, spezifische Interfaces zu definieren.
Man könnte zum Beispiel ein Interface nur zum Lesen von allgemeinen Mitarbeiterdaten, ein zweites zum Lesen von Clusterdaten, wie zum Beispiel die Abrechnung, und ein drittes zur Verwaltung von Beziehungen zu anderen Objekten erstellen. Klassen implementieren dann nur die Schnittstellen, die sie wirklich benötigen. Dies reduziert unnötige Abhängigkeiten und macht den Code schlanker und verständlicher.
Vorteile des Interface Segregation Principle:
- Vereinfacht Wiederverwendung, Tests und Wartung durch Aufteilung der Verantwortlichkeiten
- Isoliert Klassen vor Fehlern durch die Einführung klarer Grenzen
- Ermöglicht das Ersetzen von Funktionen, ohne dass verwandte Klassen verstanden werden müssen
- Senkt die kognitive Belastung durch Isolierung von Themen
- Fokussiert die Aufmerksamkeit auf einen einzigen Aspekt
Dependency Inversion Principle
Das Dependency Inversion Principle besagt, dass Module höherer Ebenen nicht von Modulen niedrigerer Ebenen abhängen sollten; beide sollten von Abstraktionen abhängen.
Anstatt dass eine übergeordnete Logik-Klasse (z.B. zur Bonusberechnung) eine untergeordnete, konkrete Klasse (z.B. zum Lesen von Gehaltsdaten einer bestimmten Mitarbeitergruppe) direkt erzeugt, sollte sie sich auf ein Interface verlassen. Die konkrete Klasse, die die Datenbeschaffung übernimmt, wird dieser Logik-Klasse von außen übergeben – ein Prozess, der als Dependency Injection bekannt ist. Dies entkoppelt die Business-Logik von technischen Details und macht sie hochgradig flexibel und testbar, da man für Tests einfach eine Dummy-Datenquelle übergeben kann.
Vorteile des Dependency Inversion Principle:
- Ermöglicht die Wiederverwendbarkeit von High-Level-Klassen durch Einfügen von Klassen
- Da Implementierungen ausgetauscht werden können, werden Änderungen auf niedriger Ebene erleichtert
- Code-Vereinfachung durch einheitliches Arbeiten mit alternativen Klassen
- Verbessert die Prüfbarkeit
Die Brücke zu S/4HANA, H4S4 und Clean Core
Aber warum ist das alles genau jetzt so entscheidend? Die Spielregeln in der SAP-Welt haben sich grundlegend geändert. Die monolithische On-Premise-Architektur weicht ab von einer hybriden Landschaft aus In-App-Erweiterungen, Side-by-Side-Entwicklungen auf der Business Technology Platform (BTP) und einer klaren Cloud-First-Strategie. Monolithischer, prozeduraler Code erweist sich in einem solchen dynamischen Umfeld als hinderlich.
Gut strukturierter und entkoppelter Code, wie er durch SOLID-Prinzipien entsteht, lässt sich hingegen mühelos in moderne Architekturen überführen. Eine saubere, gekapselte Klasse lässt sich leicht als RESTful-Service für eine Cloud-Anwendung freigeben; ein Spaghetti-Code-Report hingegen nicht.
Gerade die HCM-Welt steht mit H4S4 (HCM for S/4HANA) vor großen Herausforderungen. Viele über Jahre gewachsene Kundenerweiterungen sind prozedural und eng mit dem Core verwoben. Wer jetzt damit beginnt, seine Z-Entwicklungen nach SOLID-Prinzipien zu modernisieren, investiert direkt in die Zukunftsfähigkeit seiner HR-IT-Landschaft.
Letztendlich sind die SOLID-Prinzipien die technische Blaupause für eine erfolgreiche Clean-Core-Strategie. Anstatt den SAP-Standard zu modifizieren, werden Erweiterungen über definierte Schnittstellen sauber angebunden. Das Ergebnis: Die Abhängigkeit vom Kern wird drastisch reduziert, was zukünftige S/4HANA-Upgrades deutlich schneller, einfacher und kostengünstiger macht.
Fazit und Ausblick: Solid Principles für einen zukunftssicheren Clean Core
SOLID ist kein abstraktes, akademisches Konzept, sondern ein unverzichtbares und praktisches Werkzeugset für alle modernen SAP-Entwickler:innen. In einer Welt, die von S/4HANA, der Cloud und dem Clean-Core-Gedanken geprägt ist, liefern diese fünf Prinzipien das Fundament, um robusten, flexiblen und vor allem zukunftssicheren Code zu schreiben.
Der beste Weg, um mit den SOLID-Prinzipien zu starten, ist klein anzufangen. Sie müssen nicht Ihr gesamtes System auf einmal umbauen. Nehmen Sie sich Ihr nächstes kleines Projekt vor und versuchen Sie, ganz bewusst das Single Responsibility Principle anzuwenden, indem Sie Logik in mehrere kleine Klassen aufteilen. Diskutieren Sie diese Prinzipien in Ihrem nächsten Code Review. Ein gemeinsames Verständnis im Team ist der Schlüssel zum Erfolg.
Sollten Sie Hilfe bei der S/4HANA-Umstellung benötigen, können Sie sich gerne jederzeit an uns wenden.
Möchten Sie mehr über Clean Code im Allgemeinen wissen? In unseren Blog-Artikeln ABAP Clean Code Guidelines – interessiert mich das wirklich erfahren Sie noch mehr darüber.
