Separation of Concerns
Du liest eine Funktion die gleichzeitig Geschäftslogik berechnet, HTML rendert und Daten in die Datenbank schreibt. Jede Änderung ist ein Risiko — weil du nie weißt, was du mitänderst. Das passiert, wenn Verantwortlichkeiten vermischt werden.
Separation of Concerns bedeutet: Jeder Teil deines Systems hat genau eine Verantwortung. Und nur eine.
Denk an ein Restaurant: Der Koch kocht. Der Kellner serviert. Der Kassierer kassiert. Keiner macht den Job des anderen — und genau deshalb funktioniert es.
In Software kennst du das Prinzip aus der Drei-Schichten-Architektur: Präsentation, Geschäftslogik, Datenhaltung. Jede Schicht kümmert sich um ihren Bereich. Aber Separation of Concerns geht tiefer — es gilt für jede Ebene, jede Klasse, jede Funktion.
Der Test ist einfach: Wenn du einen Teil deines Systems ändern musst und dabei einen anderen Teil verstehen musst der nichts damit zu tun hat — dann sind die Concerns nicht getrennt.
Merke: Trennung der Verantwortlichkeiten ist das Fundament jeder guten Architektur.
Trennung der Verantwortlichkeiten ist das Fundament jeder guten Architektur. separation of concerns is the foundation of every good architecture.