Anzeige
Anzeige
UX & Design
Artikel merken

Prinzipien der Software-Entwicklung einfach erklärt: SOLID

Wer ernsthaft versucht, sich selbst das Programmieren beizubringen, wird schnell auf Objektorientierung, ihre Prinzipien und Designs treffen. In diesem Artikel stellen wir euch eine Methode vor: SOLID.

Von Mario Janschitz
3 Min. Lesezeit
Anzeige
Anzeige

Zuerst das Problem lösen, dann programmieren. (Foto: © DDRockstar - Fotolia.com)

SOLID: Ein Crashkurs

Einer der Urväter hinter den Prinzipien objektorientierten Designs ist Uncle Bob – Robert C. Martin. Er ist einer der Software-Engineers hinter der Entwickler-Bibel und Nummer-1-Lektüre für angehende Programmierer: dem „Agile Manifesto“.

Anzeige
Anzeige

Das objektorientierte Programmieren kennt verschiedenste Prinzipien, die zu gutem objektorientierten Design führen sollen. In diesem Artikel wollen wir euch eine Gruppe von Prinzipien vorstellen, die von Robert C. Martin mit dem Acronym „SOLID“ geprägt und zusammengefasst wurden. SOLID verspricht eine höhere Wartbarkeit von Software. Hinter dem kryptischen Akronym verbergen sich die Prinzipien „Single Responsiblity“, „Open-Closed“, „Liskovsche Substitution“, „Interface Segregation“ und „Dependency Inversion“.

anfänger

SOLID hilft euch bessere Entwickler zu werden. (Foto: © DDRockstar – Fotolia.com)

„S“ wie „Single-Responsibility-Prinzip“

„Es sollte nie mehr als einen Grund dafür geben, eine Klasse zu ändern.“ Robert C. Martin

Die Kernaussage des Prinzips ist, dass jede Klasse nur genau eine fest definierte Aufgabe zu erfüllen hat. Wenn eine Klasse mehrere Verantwortungen zu tragen hat, führt das zu Schwierigkeiten bei zukünftigen Änderungen und das Fehlerrisiko steigt. Eine hohe Kohäsion – also alle Methoden innerhalb einer Klassen haben einen starken gemeinsamen Bezug – sollte angestrebt werden.

Anzeige
Anzeige

„O“ wie „Open-Closed-Prinzip“

„Module sollten sowohl offen (für Erweiterungen) als auch geschlossen (für Modifikationen) sein.“ Bertrand Meyer

Dieses Prinzip besagt, dass Klassen, Methoden, Module et cetera so entwickelt werden sollen, dass sie einfach zu erweitern sind – ohne aber ihr Verhalten zu ändern. Das beste Beispiel dafür ist wohl die Vererbung. Das Verhalten einer Klasse wird nicht verändert, erhöht aber trotzdem die Funktionalität der Software. Auch das Überschreiben von Methoden verändert nicht das Verhalten der Basisklasse, sondern nur die Methoden der abgeleiteten Klasse.

Anzeige
Anzeige

„L“ wie „Liskovsches Substitutionsprinzip“

„Sei q(x) eine Eigenschaft des Objektes x vom Typ T, dann sollte q(y) für alle Objekte y des Typs S gelten, wobei S ein Subtyp von T ist.“ Barbara Liskov

Einfach gesagt: Das (Ersetzungs-)Prinzip sagt aus, dass eine Subklasse immer alle Eigenschaften der Superklasse erfüllen und immer als Objekt der Superklasse verwendbar sein muss. Eine Subklasse darf somit Erweiterungen enthalten, aber keine grundlegenden Änderungen.

„I“ wie „Interface-Segregation-Prinzip“

„Clients sollten nicht dazu gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden.“ Robert C. Martin

Wie der Name erahnen lässt, geht es hierbei darum, Interfaces aufzuspalten beziehungsweise sie nicht unnötig groß zu machen. Ein Interface soll also so gestaltetet sein, dass die Anforderungen des Clients erfüllt werden können. Damit soll vermieden werden, dass ein Client mehrere Interfaces nutzen muss, die er für seine eigentliche Anforderung gar nicht benötigt werden.

Anzeige
Anzeige

„D“ wie „Dependency-Inversion-Prinzip“

„A. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen. B. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“ Robert C. Martin

Das Prinzip beschäftigt sich mit der Abhängigkeit von abgeschlossenen funktionalen Einheiten einer Software – also Modulen. In Modulen, die eine höhere Hierarchie innerhalb der Software aufweisen, werden generelle Abläufe beschrieben, die von spezielleren Modulen verwendet werden. Je niedriger das Modul innerhalb der Hierachie, desto spezifischere Probleme löst es.

Wenn ein hierarchisch niedriges Modul von einem höherliegendem Modul abhängig ist, entsteht ein Problem. Änderungen in spezifischen Modulen ändern somit das Verhalten von höher liegenden und generellen Modulen, eine zyklische Abhängigkeit entsteht und die Architektur und das Design der Software werden unnötig komplex. Das Prinzip soll also eine Invertierung der Abhängigkeiten sicherstellen.

Habt ihr das „Agile Manifesto“ gelesen?

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
2 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Gute Konzepte

Nur Anmerkungen:
„Is-A“-Beziehung vs. „Has-A“-Beziehungen.
Eine LKW ist kein Auto mit mehr Achsen und einem zweiten Innenraum(dem Frachtraum) also kann man ihn nicht vom Auto ableiten. Ein Auto ist ein Kraftfahrzeug, ein LKW ist ein Kraftfahrzeug, ein Mofa ist ein Kraftfahrzeug. Alles „is-a“-Kraftfahrzeug. Also ist die Ableitung erlaubt.
Das Problem bei Ableitungen ist, das man in der Oberklasse veraltete Einstellungen überarbeiten muss. Autos haben Elektro, Benzin, Hybrid-Antrieb. also muss man das in der „Kraftfahrzeug-Klasse“ überarbeiten und die alten Einstellungen „Anzahl Zylinder, PS/kW, Tank-Größe Liter, Benzin/Diesel/Super, …“ in ein Antriebs-Klasse und dort in Benzin/Dieselmotor auslagern was ja kein Problem ist, weil man abstrakt denkt. Das führt aber oft zu richtig vielen verschiedenen Klassen. Und wie man bei „Normalisierung“ von Relationalen Datenbanken weiss, endet es oft bei der (ich glaube) dritten Stufe obwohl es auch noch vierte Stufen gibt die aber andere Nachteile bringen. Auch muss man zig Klassen in zig Tabellen in SQL ablegen oder dünn besetzte Tabellen haben oder Teile (meist nicht alles!) in NoSQL realisieren. Die meisten Systeme haben keine flexiblen Kontakte sondern nur Telefon/Fax und bestenfalls email aber meist kein icq, skype, googletalk,… oder Referenzen auf Pinterest, xing, linkedin,… accounts was schon seit Jahren normal sein müsste.

Obwohl es OO schon 30 Jahre lang gibt, gibts vielleicht immer noch keine brauchbaren Infografiken für Klassenstrukturen wo man alles wichtige im Schema sofort erkennt. Vielleicht sollte man von Zoologie lernen wo tausende Ausgestorbener Tiere, Übergangstiere, Zwischenstufen usw. dargestellt werden. Speziell bei Insekten.

Konzepte nutzen wenig wenn man sie schlecht umsetzen kann. Grafisch gute Aufbereitung ist wichtiger als früher wo man am Terminal coden musste. Das führt auch zu schnellerer Lernkurve und erfolgreicheren Teams und besserer Wartbarkeit. Lego sollte das vorbild sein. wie bei den Modulen erklärt sollte man sie wie einzelne Steine oder z.B. Garten-Schlauch-Environment mit definierten Anschlüssen problemfrei austauschen und andocken können. Stattdessen sind es Puzzles wo jedes Teil praktisch nicht austauschbar ist und Wartung immer teurer wird und keiner Durchblickt. Wo haben die wohl alle gelernt ?

Ergänzung zu Interfaces weil es vor einer Weile irgendwo Streit deshalb gab: Man sollte sehr offen in dem sein, was man annimmt/einliest aber ultrapräzise darin, was man ausgibt. Gilt wohl eigentlich für TCP aber sollte man auch sonst nutzen. Man kriegt und sendet heutzutagen ja aus und zu zig verschiedenen Systemen Daten und deren Entwickler kann man leider nicht zwingen, korrekte Daten zu liefern. APIs sind ja leider copyrightet aber kann jemand M$ zwingen, sich an das OfficeXML oder Kherberos oder Javascript oder HTML5 zu halten ?
http://www.golem.de/news/java-rechtsstreit-us-justiz-befuerwortet-urheberrecht-auf-apis-1505-114287.html
Bei Java wurde M$ wohl vor vielen Jahren schon durch Urteil gezwungen, das API nicht (wie bei Jscript, M$-Kherberos,…) abzuändern um proprietäre inkompatible Inseln zu schaffen.

Weil man XML mit xmllint in gut oder schlecht einteilen kann, macht man sich damit oft ähnlich beliebt wie der Doping-Kontrolle in bekannten Doping-Sportarten. Die Folgen liest man täglich in den Sicherheits-Lücken-Berichten. Magento wurde doch neulich wieder ausgelesen und Kreditkarten-Nummern abgegriffen.

Ehre, Ehrlichkeit, Gesundheit usw. kann man nicht kaufen. D.h. die Konzepte helfen in falschen Umgebungen oft trotzdem leider nicht.
Welches IT-Großprojekte waren erfolgreich ?
Wie weit kommt man wenn man korrekt und sauber arbeitet ? So weit wie doping-freie Sportler in bestimmten Sportarten ?

Die Qualität der wahren Programmierung liest man täglich.
https://t3n.de/news/whatsapp-client-chats-euren-618287/ (Kommentare)
https://t3n.de/news/remote-code-execution-windows-10-1261490/
http://www.golem.de/news/it-sicherheit-standardschluessel-gefaehrdet-saps-datenbank-hana-1506-114783.html
oder wohl auch noch Magento, Cisco und Samsung diese Woche. Und das sind ja überwiegend keine komplizierten Angriffe.

Antworten
?

Tippfehler: Ein Interface soll also so gestaltetet sein

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige