Uncategorized
SOLID – Die 5 Prinzipien für objektorientiertes Softwaredesign
Warum ist guter Code so wichtig?
SOLID, das sind fünf Prinzipien zum Entwurf und der Entwicklung wartbarer Softwaresysteme. Das Wissen um und über diese Prinzipien sollte zur Basis jedes Softwareentwicklers gehören.
- Code schreiben ist ein relativ kleiner Teil der Softwareentwicklung.
- Ca. 80% der Kosten sind Wartungskosten
- Es wird wenig neuer Code geschrieben.
Die hauptsächliche Arbeit besteht aus Änderungen.
Table of Contents
Single-Responsibility-Prinzip
Contents
Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben solle. Verantwortung wird hierbei als „Grund zur Änderung“ definiert:
“There should never be more than one reason for a class to change.”
„Es sollte nie mehr als einen Grund dafür geben, eine Klasse zu ändern.“
Der größte Anteil an der Arbeit ist nicht das Codieren, sondern das Verstehen (Lesen) von Code.Fehlerbehebungen in unverständlichem Code erzeugen schnell neue Fehler.
Wenn am Anfang des Projektes auf Kosten der Codequalität Zeit gespart wird, wird dies am Ende des Projektes ein Vielfaches der eingesparten Zeit kosten.Prinzipiell ist jedem (erfahrenen) Entwickler bekannt, dass schlechter Code dieArbeit behindert.
Allerdings passiert es immer wieder, dass durch hohen Druckchaotischer Code geschrieben wird, damit Termine eingehalten werden können.
Der schlechte Code führt dazu, dass die Arbeit gleichlangsamer wird und Termine nicht eingehalten werden.
Es gibt nur einen Weg: Von Anfang an muss sauberer Code geschrieben werden!Was ist sauberer Code?
Sauberer Code ist gut zu lesen.
Erkann auch von anderen Entwicklern verstanden werden.
Klassen und Methoden sind auf die Erfüllung einer Aufgabe ausgerichtet und werden nicht durch Nebenaufgaben „verunreinigt“.
Open-Closed-Prinzip
Das Open-Closed-Prinzip besagt, dass Software-Einheiten Erweiterungen möglich machen sollen (dafür offen sein), aber ohne dabei ihr Verhalten zu ändern (ihr Sourcecode und ihre Schnittstelle sollte sich nicht ändern).
Es wurde 1988 von Bertrand Meyer folgendermaßen formuliert:
“Modules should be both open (for extension) and closed (for modification).”
„Module sollten sowohl offen (für Erweiterungen), als auch geschlossen (für Modifikationen) sein.“
Die Abhängigkeiten zu anderem Code sind auf ein Minimum begrenzt.Sauberer Code ist gut zu testen.Es gibt keine Duplizierungen.
Liskovsches Substitutionsprinzip
Interface-Segregation-Prinzip
Das Interface-Segregation-Prinzip dient dazu, zu große Interfaces aufzuteilen. Die Aufteilung soll gemäß den Anforderungen der Clients an die Interfaces gemacht werden – und zwar derart, dass die neuen Interfaces genau auf die Anforderungen der einzelnen Clients passen.
Das Prinzip wurde von Robert C. Martin 1996 folgendermaßen formuliert:
“Clients should not be forced to depend upon interfaces that they do not use.”
„Clients sollten nicht dazu gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden.“
Der Code enthält keine Überraschungen.
Guter Code motiviert Alle Beteiligten sind stolz auf ihre Arbeit.Das Programmieren macht mehr Spaß.
Er enthält weniger Fehler.
Guter Code ist einfacher zu testen.
Dependency-Inversion-Prinzip
Das Dependency-Inversion-Prinzip beschäftigt sich mit der Reduktion der Kopplung von Modulen. Es besagt, dass Abhängigkeiten immer von konkreteren Modulen niedriger Ebenen zu abstrakten Modulen höherer Ebenen gerichtet sein sollten.
“A. High-level modules should not depend on low level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.”
Embedded System Software & Hardware Developer.
