Single Responsibility Principle (SRP) der SOLID Principles von Uncle Bob

[@Luca_040]

Du bist echt genial! Sehr gute Vorbereitung auf mein Vorstellungsgespräch ❤

[@marcusreinicke]

Hallo David, ich bin hier voll und ganz bei Dir. Wie Du schon sagst, diese Prinzipien gibt es schon lange. Jedoch wurden sie viele Jahre nicht gelebt. Ich habe in den letzten Jahren einige Systeme gesehen, wo die Grenzen fließend waren / sind. Wenn sich was ändert, müssen viele Programmteile / Komponenten mit geändert werden. Diese müssen dann wieder getestet werden, was wieder ein zusätzlicher Aufwand bedeutet. Komponenten sind derart verschachtelt, das in einigen Jahren, oder sogar früher, die Entwickler eine komplette Neuentwicklung empfehlen müssen, weil die Wartung und Weiterentwicklung nicht mehr tragbar ist. Und natürlich sind die Entwickler immer frustrierter, weil man sich mit solch einem Spagetti System auseinander setzen muss. Deshalb sollte ein jedes Team sich dieser Themen annehmen, wenn nicht schon erfolgt. Als Schlußfolgerung schreibt Robert C. Martin in seinem Buch zum "SRP" (ich muss zugeben, ich habe immer SAP verstanden, wusste aber was Du meinst :-) ) Das Prinzip der Einzelverantwortung ist eines der einfachsten Prinzipien, aber eines der am schwierigsten zu erfüllenden. Die Zusammenführung von Verantwortlichkeiten ist etwas, das wir natürlich tun. Diese Verantwortlichkeiten zu finden und zu trennen ist ein großer Teil dessen, worum es beim Software-Design wirklich geht. In der Tat kommen die übrigen Prinzipien, die wir diskutieren, auf die eine oder andere Weise auf dieses Thema zurück. Robert C. Martin oder einfach Oncle Bob hat von dem Buch "Agile Software Development, Principles, Patterns, and Practices 1st edition by Martin, Robert C. (2002)" weitere Versionen rausgebracht. Ich habe das "Agile Principles, Patterns, and Practices in C#", dass ist von 2006 und kann es auch sehr empfehlen. Gruß Marcus

[@DavidTielke]

Hallo Marcus, da hast du vollkommen recht und deshalb liegen mir diese Prinzipien auch so am Herzen. Die zu verstehen ist eine Sache, sie zu verstehen und anwenden zu können eine komplett andere. Deshalb habe ich versucht die Videos so aufzubauen, dass jeder danach direkt loslegen kann weil nur durch Berücksichtigung von z.B. dem Single Responsibility Principle kann man schon einen ungemeinen Unterschied feststellen. Schön das es Dir gefallen hat :) Gruß David

[@-mwolf]

9:27 beginnt das Video

[@techdesign2832]

David, tolle Ansätze, welche nicht nur für die Softwareentwicklung interessant sind. Gerade im Bereich der Data Warehouse Entwicklung ist die Trennung der BI Layer sinnvoll, so dass mehrere Entwickler am System gleichzeitig arbeiten können. 😉 Gruß Leschek

[@MrFrankie180]

Decompose deutsch ist "Entflechten" :-)

[@lukasb9163]

#fragdavid Immer wieder erwähnst du die Aspektschicht bzw. in deinem Besiepiel den "Cross-Cutting-Layer". Wie ist so ein Layer tatsächlich aufgebaut? Ein Namespace mit vielen Klassen? Oder eine Cross-Cutting-Klasse, die wiederum andere Klassen aufruft? Welche Klassen gehören hier rein, bzw. noch wichtiger, welche gehören dort nicht rein um am Ende nicht eine Art "Utils.cs" zu erschaffen? Vielleicht gibt es dazu ja auch mal ein Video. :) Besten Dank!

[@martinbernasconi9208]

Hallo Lukas! Ein "Layer" ist nach Tielke die nächsthöhere Strukturierungseinheit über Komponenten. Layer gruppieren also Komopnenten (und keine Klassen), wobei dies primär als "Solution-Verzeichnis" auf Dateiebene geschieht. Siehe hierzu diese beiden Videos von David: Die verschiedenen Strukturierungseinheiten: kzbin.info/www/bejne/eXiZmqeubpuqp5o Wie eine Solutionmappe aufgebaut wird: kzbin.info/www/bejne/haW1k2Z-hNSMr6c Ebenfalls in diesem Kontext zu empfehlen: Aufbau einer Mehrschichtenarchitekur: kzbin.info/www/bejne/r3rdqq1qbqZsp5I Schneiden von Komponenten: kzbin.info/www/bejne/enTHpmx_gpeajM0 Im Cross-Cutting-Layer werden also alle Komponenten (Projekte / Bibliotheken) geparkt, die von *mehreren* Komponenten aus *unterschiedlichen* Schichten benötigt werden. Das klassische Beispiel ist "Logging" und andere Monitoring-Komponenten (z.B. "Performance Monitoring", "Operations Monitoring"). Komponenten, die *nicht* in den Cross-Cutting-Layer gehören, sind auf jeden Fall solche, die ausschließlich zu den Layern GUI, Business Logic oder Datenbank gehören. Diese Regel mag plumper klingen als sie ist, denn damit werden alle Komponenten potentiell vom Cross-Cutting-Layer ausgeschlossen, die irgendwie mit Oberfläche, der modellierten Businessumgebung oder mit Datenbank zu tun haben, und das sind vermutlich mehr als 95% aller Funktionalität in den typischen Business-Projekten. Was bleibt sind meistens Komponenten / Tools / Features, die in jedem beliebigen Projekt eingesetzt werden könnten, weil sie nicht Teil einer bestimmten Businessumgebung sind (z.B. log4net). Viele Grüße!

[@DavidTielke]

Hallo Lucas, für alle Interessierten wurde die Frage hier beantwortet: kzbin.info/www/bejne/q3ebhKaClNicrdU Gruß David

[@DavidTielke]

Hey Martin, gut beantwortet, Top! Gruß David

[@Blackeye1987]

hmm schade der blogeintrag fehlt 😕

[@TheJulietteCharlie]

Alles gut. Aufteilen, schneiden, modularisieren ist dabei keine so einfache Aufgabe wie dargestellt „fachlich/technisch“. Man muss ehrlicherweise sagen, dass sich Anforderungen so verändern können, dass auch die Schnitt- oder Grenzlinien, die wir zwischen Komponenten einst gut überlegt haben, verändern. Wer es mit SRP ernst meint, kommt bei allem Fortschritt auch schnell an Grenzen: eine Atomisierung von Mini-Verantwortlichkeiten - verteilte Zuständigkeit - hat oft einen erhöhten Koordinationsaufwand als Schattenseite zur Folge. Und querschneidende Aspekte, die Einzug halten mit neuen Anforderungen können einem das Genick brechen.

[@DavidTielke]

Hey, da muss ich Dir widersprechen - wenn Du beispielsweise nach SRP modularisierst, dann schneidest Du fachlich nach Aufgaben deine Klassen, Komponenten usw. und das ist sehr resistent gegenüber Anforderungsänderungen. Würdest Du so eine Modularisierung ändern müssen, würde das heißen, dass Deine Anforderungen vorher fachlich falsch gewesen sind- weil Du danach eine vollkommen andere Aufgabe implementieren musst. Das ist dann aber kein Architekturproblem, sondern ein massives Problem in Deiner Anforderungsanalyse. So ein von Dir beschriebenes Szenario ist mir in über 10 Jahren als Architekt noch nie passiert :) Ein Beispiel für eine solche Modularisierung findest Du hier: kzbin.info/www/bejne/b5OlqpeeiKefadk Gruß David

[@HansWurst-mi8gg]

Vielen Dank für die Erläuterungen. Als Anfänger dieses Prinzips habe ich eine Verständnisfrage zu ihrem Beispiel: der "BillValidator" hat bestimmt mehrere Sachen die er in einer Rechnung prüfen muss. Wird für jedes dieser Prüfung wieder eine separate unterlagerte Komponente (z. b. Klasse) gebaut? Mit meiner Frage möchte ich herausfinden, wenn hört man auf in untergelagerten Kompenten eine erneute Teilung vor zu nehmen. Gestatten Sie mir eine Zusatzfrage: Wenn man seine Software nach dem SRP strukturiert, wird man wohl viel kleine Klasse erhalten, oder? Wird das nicht irgendwann unübersichtlich?

[@i.a.9776]

Schönes Thema... Wie kann man das als Programmierer lernen? Gibt's ein benifit Link für C# ?

[@Luca_040]

Bei der Seite dotnetpro gibt's Artikel von ihm, ist ganz gut

[@Yetipfote]

Ich finde das ganze eher philosphisch, da es immer weiter in's Detail fortgesetzt werden kann: wie zerteilt man eine Klasse in sinnvolle Methoden? In diesem Methoden gibt es auch lokalen state und lokale Prozesse, die diesen State in was anderes umformen. Wie schneidet (und benennt) man die sinnvoll? Die große Frage, die auf allen Abstraktionsebenen bis hinunter zur assembler-Anweisung (und eigentlich noch darüber hinaus in die Elektrotechnik des Computers) reicht ist: wie abstrahiere ich die Welt so, dass sie einfach genug ist, sodass sie eine überschaubare und managebare Ordnung darstellt, und gleichzeitig komplex genug , damit ich bestimmte Bedürfnisse des Users über einen möglichst langen Zeitraum treffend, zuverlässig und effizient erfüllen kann?

[@prostmahlzeit]

#fragdavid Wie kann man constructor injection ohne DI framework in AOT kompilierten Sprachen wartbar anwenden ohne Teleskop konstruktor, servicelocator oder Singleton antipattern zu benutzen? Beispiel: ILogger wird erst im Unterobjekt auf Dritter Ebene benötigt, also muss das Objekt auf zweiter ebene einen logger bereitstellen, also muss das Objekt auf erster Ebene den Logger bereitstellen -> Teleskop Konstruktoren in root mit dutzenden durchgeschleiften dependencies ODER servicelocator aka globals. Spontan fällt mir nur eine riesige init routine ein, welche bottom up alle Objekte erzeugt... aber so programmiert ?niemand? Weil man Bottom objekte erst in der Zukunft kennen kann.

[@DavidTielke]

Hey Denis, wo genau ist das Problem wenn du ein DI Container verwendest? Verstehe glaub das Problem nicht... Gruß David

[@prostmahlzeit]

@@DavidTielke hallo David, mit DI Container gibt es kein Problem. Habe inzwischen gesehen dass es auch DI Frameworks für c++ gibt. Kenne selbst kein einziges c++ Projekt wo DI Frameworks benutzt worden sind.

[@r6turboo]

Leider sehr langgezogen. Das hätte man wahrscheinlich auch alles zeitlich etwas knackiger erklären können.