Solide Architektur
Die SOLID-Prinzipien sind fünf grundlegende Prinzipien der objektorientierten Programmierung und des Designs, die dazu beitragen sollen, verständlichen, flexiblen und wartbaren Code zu schreiben. Sie stehen für:
S - Single Responsibility Principle (SRP): Eine Klasse sollte nur eine einzige Verantwortlichkeit haben. Das bedeutet, eine Klasse sollte nur für eine einzige Aufgabe zuständig sein und nur einen Grund haben, geändert zu werden.
O - Open/Closed Principle (OCP): Software-Entitäten (Klassen, Module, Funktionen, etc.) sollten offen für Erweiterungen, aber geschlossen für Veränderungen sein. Das bedeutet, dass man bestehende Klassen erweitern kann, ohne sie zu verändern.
L - Liskov Substitution Principle (LSP): Objekte einer Basisklasse sollten durch Objekte einer abgeleiteten Klasse ersetzt werden können, ohne dass die Korrektheit des Programms beeinträchtigt wird. Das bedeutet, dass die Unterklassen die Erwartungen der Basisklasse erfüllen müssen.
I - Interface Segregation Principle (ISP): Viele spezialisierte Schnittstellen sind besser als eine allgemeine. Das bedeutet, dass eine Klasse nicht gezwungen sein sollte, Schnittstellen zu implementieren, die sie nicht benötigt.
D - Dependency Inversion Principle (DIP): Abhängigkeiten sollten von Abstraktionen abhängen und nicht von konkreten Implementierungen. Das bedeutet, dass hochrangige Module nicht von niederrangigen Modulen abhängen sollten, sondern beide von Abstraktionen.
Diese Prinzipien helfen, den Code modular, leicht verständlich und anpassbar zu halten, was langfristig die Wartbarkeit und Erweiterbarkeit verbessert.
Gesetz von Convey
Das Gesetz von Conway, benannt nach dem Informatiker Melvin Conway, besagt:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
In deutscher Übersetzung:
Jede Organisation, die ein System entwirft (weit gefasst), wird ein Design produzieren, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.
Das bedeutet, dass die Architektur eines Systems oder Produkts oft die Kommunikationswege und Hierarchien innerhalb der Organisation widerspiegelt, die das System entwickelt hat. Wenn beispielsweise Teams in einer Organisation wenig miteinander kommunizieren, ist es wahrscheinlich, dass auch die entwickelten Systeme oder Module schlecht integriert sind oder isoliert voneinander arbeiten. Das Gesetz von Conway hebt die enge Verbindung zwischen der organisatorischen Struktur und der Systemarchitektur hervor und zeigt auf, wie wichtig effiziente Kommunikations- und Kollaborationsprozesse für die Entwicklung guter Software sind.