Dieses Prinzip besagt, dass eine Klasse nur eine einzige Verantwortung haben sollte, sodass es auch nur einen Grund gibt, sie zu \u00e4ndern.\u00a0<\/span><\/p>\n Statt einen riesigen Funktionsbaustein zu erstellen, der alles erledigt \u2013 vom Lesen der Daten \u00fcber die Transformation, der Anzeige in einem ALV-Grid bis hin zum Versenden von E-Mails \u2013 sollte beim Single Responsibility Principle die Logik aufgeteilt werden.\u00a0<\/span><\/p>\n Sinnvoller ist es, <\/span>spezialisierte Klassen<\/b> zu schaffen: eine f\u00fcr den reinen Datenbankzugriff, eine weitere f\u00fcr die Mailversand und eine dritte f\u00fcr die Verarbeitung von Daten, eine f\u00fcr die Anzeige, usw. Ein \u00fcbergeordneter Controller kann diese kleinen, fokussierten Klassen dann orchestrieren, was die Wartung und Testbarkeit enorm verbessert.<\/span><\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n <\/p>\n\n\n\n Beim Open Closed Priciple sollten Software-Einheiten <\/span>offen f\u00fcr Erweiterungen, aber f\u00fcr Modifikationen geschlossen sein<\/b>.\u00a0<\/span><\/p>\n 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\u00e4ndert werden.\u00a0<\/span><\/p>\n Besser ist es, ein allgemeines Interface f\u00fcr die Behandlung von Abwesenheiten zu definieren. F\u00fcr jede Abwesenheitsart wird dann eine eigene Klasse erstellt, die dieses Interface implementiert. Eine Factory-Klasse kann die passende Implementierung zur Laufzeit ausw\u00e4hlen, sodass f\u00fcr neue Abwesenheitsarten lediglich eine neue Klasse hinzugef\u00fcgt werden muss, ohne den alten Code anzufassen.<\/span><\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n <\/p>\n\n\n\n Nach dem Liskov Substitution Principle muss eine abgeleitete Klasse ihre Basisklasse jederzeit ersetzen k\u00f6nnen, ohne Fehler zu verursachen. Das bedeutet, eine Unterklasse muss sich immer so verhalten, wie es die Oberklasse vorgibt.\u00a0<\/span><\/p>\n Stellt man sich eine Basisklasse Mitarbeiter mit einer Methode zur Bonusberechnung vor, so m\u00fcssen alle abgeleiteten Klassen \u2013 wie Vertriebsmitarbeiter, Consultant oder Entwickler \u2013 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.<\/span><\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n <\/p>\n\n\n\n Sicherheit, dass eine Implementierung ausgetauscht werden kann, ohne ihr Verhalten zu \u00e4ndern<\/p>\n\n\n\n Dem Interface Segregation Principle zufolge sollte keine Klasse gezwungen sein, von Methoden abh\u00e4ngig zu sein, die sie nicht verwendet. Anstatt ein riesiges \u201eGott-Interface\u201c mit 50 Methoden f\u00fcr den gesamten HR-Bereich zu schaffen, ist es besser, <\/span>viele kleine, spezifische Interfaces<\/b> zu definieren.<\/span><\/p>\n Man k\u00f6nnte 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\u00f6tigen. Dies reduziert unn\u00f6tige Abh\u00e4ngigkeiten und macht den Code schlanker und verst\u00e4ndlicher.<\/span><\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n <\/p>\n\n\n\n <\/p>\n Das Dependency Inversion Principle besagt, dass Module h\u00f6herer Ebenen nicht von Modulen niedrigerer Ebenen abh\u00e4ngen sollten; beide sollten von Abstraktionen abh\u00e4ngen.\u00a0<\/span><\/p>\n Anstatt dass eine \u00fcbergeordnete 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 \u00fcbernimmt, wird dieser Logik-Klasse von au\u00dfen \u00fcbergeben \u2013 ein Prozess, der als <\/span>Dependency Injection<\/b> bekannt ist. Dies entkoppelt die Business-Logik von technischen Details und macht sie hochgradig flexibel und testbar, da man f\u00fcr Tests einfach eine Dummy-Datenquelle \u00fcbergeben kann.<\/span><\/p>\n <\/p>\n <\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n <\/p>\n\n\n\n Aber warum ist das alles genau jetzt so entscheidend? Die Spielregeln in der SAP-Welt haben sich grundlegend ge\u00e4ndert. 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.<\/p>\n\n\n\n Gut strukturierter und entkoppelter Code, wie er durch SOLID-Prinzipien entsteht, l\u00e4sst sich hingegen m\u00fchelos in moderne Architekturen \u00fcberf\u00fchren. Eine saubere, gekapselte Klasse l\u00e4sst sich leicht als RESTful-Service f\u00fcr eine Cloud-Anwendung freigeben; ein Spaghetti-Code-Report hingegen nicht.<\/p>\n\n\n\n Gerade die HCM-Welt steht mit H4S4 (HCM for S\/4HANA) vor gro\u00dfen Herausforderungen. Viele \u00fcber 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\u00e4higkeit seiner HR-IT-Landschaft.<\/p>\n\n\n\n Letztendlich sind die SOLID-Prinzipien die technische Blaupause f\u00fcr eine erfolgreiche Clean-Core-Strategie. Anstatt den SAP-Standard zu modifizieren, werden Erweiterungen \u00fcber definierte Schnittstellen sauber angebunden. Das Ergebnis: Die Abh\u00e4ngigkeit vom Kern wird drastisch reduziert, was zuk\u00fcnftige S\/4HANA-Upgrades deutlich schneller, einfacher und kosteng\u00fcnstiger macht.<\/p>\n\n\n\n SOLID ist kein abstraktes, akademisches Konzept, sondern ein unverzichtbares und praktisches Werkzeugset f\u00fcr alle modernen SAP-Entwickler:innen. In einer Welt, die von S\/4HANA, der Cloud und dem Clean-Core-Gedanken gepr\u00e4gt ist, liefern diese f\u00fcnf Prinzipien das Fundament, um robusten, flexiblen und vor allem zukunftssicheren Code zu schreiben.<\/p>\n\n\n\n Der beste Weg, um mit den SOLID-Prinzipien zu starten, ist klein anzufangen. Sie m\u00fcssen nicht Ihr gesamtes System auf einmal umbauen. Nehmen Sie sich Ihr n\u00e4chstes 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\u00e4chsten Code Review. Ein gemeinsames Verst\u00e4ndnis im Team ist der Schl\u00fcssel zum Erfolg.<\/p>\n\n\n\n Sollten Sie Hilfe bei der S\/4HANA-Umstellung ben\u00f6tigen, k\u00f6nnen Sie sich gerne jederzeit an uns wenden.<\/p>\n\n\n\n M\u00f6chten Sie mehr \u00fcber Clean Code im Allgemeinen wissen? In unseren Blog-Artikeln ABAP Clean Code Guidelines \u2013 interessiert mich das wirklich<\/a> erfahren Sie noch mehr dar\u00fcber.<\/p>\n\n\n\n\n Die SOLID-Prinzipien sind f\u00fcnf Regeln des objektorientierten Softwaredesigns. Sie unterst\u00fctzen dabei, wartbaren, erweiterbaren, nachvollziehbaren und sauberen Code zu schreiben.<\/p>\n <\/div>\n <\/div>\n 
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n\n\nVorteile des Single Responsibility Principle:<\/h4>\n\n\n\n
\n
Open Closed Principle<\/h3>\n\n\n\n\n
<\/h2>\n <\/div>\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n\n\nVorteile des Open Closed Principle: <\/h4>\n\n\n\n
\n
Liskov Substitution Principle<\/h3>\n\n\n\n\n
<\/h2>\n <\/div>\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n\n\nVorteil des Liskov Substitution Principle:<\/h4>\n\n\n\n
Interface Segregation Principle<\/h3>\n\n\n\n\n
<\/h2>\n <\/div>\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n\n\nVorteile des Interface Segregation Principle: <\/h4>\n\n\n\n
\n
Dependency Inversion Principle<\/h3>\n\n\n\n\n
<\/h2>\n <\/div>\n\n
<\/h4>\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n\n\nVorteile des Dependency Inversion Principle: <\/h4>\n\n\n\n
\n
Die Br\u00fccke zu S\/4HANA, H4S4 und Clean Core<\/h2>\n\n\n\n
Fazit und Ausblick: Solid Principles f\u00fcr einen zukunftssicheren Clean Core<\/h2>\n\n\n\n
Was sind die Solid Principles? <\/h5>\n <\/span><\/span><\/span>\n <\/a>\n
SOLID ist nicht nur ein Schlagwort, sondern ein fundamentaler Baustein f\u00fcr die Clean-Code<\/strong>–Philosophie <\/strong>und eine technische Voraussetzung f\u00fcr eine erfolgreiche Clean-Core-Strategie<\/strong>.<\/p>\n\n\n\n Begriffsdefinitionen:<\/strong><\/p>\n\n\n\n Prinzipien sind grundlegende Regeln und Gesetze, die bei der Softwareentwicklung immer einzuhalten sind \u2013 man k\u00f6nnte sie mit der einfachsten Matheregel \u201cPunkt vor Strich\u201d vergleichen. Anders gesagt: Sie sind dazu da, um Probleme zu l\u00f6sen oder zu vereinfachen. Au\u00dferdem helfen sie Ihnen und Ihrem Team dabei, dass die resultierende Software bestimmte Eigenschaften wie Wartbarkeit, Flexibilit\u00e4t oder Wiederverwendbarkeit besitzt. Diese Eigenschaften sind abh\u00e4ngig vom jeweiligen Prinzip. <\/p>\n\n\n\n\n \n
But first: Was ist \u00fcberhaupt ein Prinzip in der Softwareentwicklung? <\/h2>\n\n\n\n
Was bedeuten die SOLID Principles ausgeschrieben?\u00a0\u00a0<\/h2>
![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/S.svg\")
\n <\/div>\n \n Single Responsibility Principle <\/h3>\n <\/div>\n \n \n
![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/O.svg\")
\n <\/div>\n \n Open Closed Principle <\/h3>\n <\/div>\n \n \n
![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/L.svg\")
\n <\/div>\n \n Liskov Substitution Principle <\/h3>\n <\/div>\n \n \n
![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/I.svg\")
\n <\/div>\n \n Interface Segregation Principle <\/h3>\n <\/div>\n \n \n
![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/D.svg\")
\n <\/div>\n \n Dependency Inversion Principle <\/h3>\n <\/div>\n \n <\/div>\n\n\n