Clean Code Developer

Nächste Frage zu einem Prinzip. Es geht immer noch um die Design Cards. Diesmal wäre meine Frage wer LSP einsetzt und wie häufig.

LSP ist mir durchaus bekannt, ich kenne das Kreis-Ellipse-Problem, die verschiedenen Lösungen desselben, ich weiß, dass quasi jedes Problem, das mit Vererbung zusammenhängt, eine Spielart dieses Problems ist und dass man da also überall LSP bedenken kann. Und trotzdem: Ich selbst bedenke bzw. nutze LSP recht selten.

Meine These ist, dass LSP besonders wichtig für Entwickler von Frameworks und Libraries ist und ansonsten nur, wenn man ein komplexes Domänenmodell hat.

Also Hand aufs Herz: Wie sieht es mit praktischen Erfahrungen zu LSP aus?

Angesichts des hartnäckigen Glaubens, dass DIP/IoC im Rahmen von SOLID den Code schon säubern werden, erlaube ich mir eine andere Meinung vorzulegen: https://ralfw.de/2018/07/dependencies-flow-down-abstractions/

Beim DIP soll man sich statt von Konkretem lieber von Abstraktem abhängig machen.

Beim DFA (Dependency Follows Abstraction) Prinzip hingegen ist es umgekehrt: Abstraktes macht sich von Konkretem (dh weniger Abstraktem) abhängig.

Ja, ich glaube, das ist viel wichtiger als das DIP. Allerdings behält das DIP durchaus Wert: für Polymorphie in streng typisierten Sprachen.

Nur wozu braucht man denn eigentlich Polymorphie? Aber das ist nochmal eine ganze andere Frage, auf die der Artikel nicht eingeht.

Grundlegend für die Säuberung von Code ist nicht Polymorphie oder Wiederverwendbarkeit, sondern Abstraktion. Und zwar inhaltliche Abstraktion.

TL;DR: Die meisten Abhängigkeiten zwischen Funktionsbausteinen in heutigen Codebasen sind dysfunktional. Sie schaden, weil sie eng koppeln, was nicht gekoppelt gehört. Da helfen dann auch nicht die tollsten Architekturmuster bis hin zur Clean Architecture. Sie lösen das falsche Problem.

Und was ist das Problem? Das Software nicht systematisch mit Blick auf saubere Abstraktionen entworfen wird.

Der Artikel führt das näher aus...

Enjoy!

PS: Wie kann es sein, dass es beim DIP und beim DFA um Abstraktionen geht, aber in scheinbar so gegensätzlicher Weise? Weil es unterschiedliche Arten von Abstraktionen gibt für verschiedene Zwecke.

Bei DFA geht es um Abstraktion durch Integration, beim DIP um Abstraktion durch Destillation.

Hallo!

CCD definiert 20 Design-Prinzipien und zu diesen hätte ich ein paar Fragen in der Hoffnung, dass ich hier Leute finde, die diese nutzen und sich damit auskennen.

Kurz zum Hintergrund:
Ich beschäftige mich seit geraumer Zeit mit solchen Prinzipien hab darüber schon vor Jahren meine Masterarbeit geschrieben und ein Wiki dazu erstellt. Basierend auf unseren "Design Types" bin ich zusammen mit einem Kollegen jetzt dabei, Prinzipien auf Karten zu bringen. Da wir erstmal "nur" 54 Karten zur Verfügung haben, es aber weitaus mehr Prinzipien gibt, müssen wir eine Auswahl treffen. Eine möglichst hilfreiche natürlich, d.h. zum einen sollten die Prinzipien möglichst viel abdecken und breit anwendbar sein, zum anderen sind spezifische Prinzipien manchmal nützlicher als allgemeine, weil sie leichter zu verwenden sind.

26 von 54 Karten sind quasi schon fertig (und bei diversen Pilotgruppen in der Erprobung), der Rest ist grob skizziert. Bisher ist IOSP nicht als Karte angedacht, wohl aber SLA. Nach meinem aktuellen Verständnis bedingt SLA IOSP. Wenn ich mich an SLA halte, halte ich mich automatisch auch an IOSP. Demnach wäre IOSP eine Spezialisierung, ein Sub-Prinzip. Für unsere Karten könnten wir im konkreten Fall deshalb auf IOSP eher verzichten als auf SLA.

Deshalb meine Fragen zu IOSP:
1. Hab ich IOSP richtig verstanden oder gibt es Fälle, wo IOSP hilft und SLA nicht ausreicht?
2. Wenn IOSP ein Sub-Prinzip ist, ist es aber vielleicht leichter anwendbar. Wie sieht es hier mit praktischen Erfahrungen aus? Wer nutzt IOSP und warum?

Liebe Gruppenmitglieder,

Daimler sucht Talente die an dem Zukunftsfeld ‘Autonomes Fahren’ mitarbeiten möchten. Jetzt können Sie sich noch bewerben für den RecruitingDay - ‘get in touch’ am 23. Juli 2018 in Sindelfingen!

Möchten auch Sie die Zukunft des Automobils mitgestalten? Möchten Sie das selbstfahrende Auto auf die Straße und in Serie bringen? Dann bewerben Sie sich noch bis zum 01. Juli 2018 unter https://www.daimler.com/karriere/das-sind-wir/events-workshops/eventuebersicht/event-detailseiten/2018/recruitingday-get-in-touch.html und entdecken Sie Ihre Einstiegsmöglichkeiten im Bereich „Autonomes Fahren“ bei Mercedes-Benz Cars der Daimler AG.

Die Kosten für die An- und Abreise werden von der Daimler AG übernommen.
Die Daimler AG freut sich auf Ihre Bewerbung.

Viele Grüße
Steffi