Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Prinzipien der Software-Entwicklung einfach erklärt: SOLID

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

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.

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“.

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.

„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.

„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.

„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?

Bitte beachte unsere Community-Richtlinien

2 Reaktionen
?

Tippfehler: Ein Interface soll also so gestaltetet sein

Antworten
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/sicherheitsluecken-softwarecodes-618503/
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

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

Abbrechen

Finde einen Job, den du liebst