Ein besseres Beispiel für Liskov ist: Quadrate sind in der OOP keine Rechtecke. Quadrat darf keine Kindklasse von Rechteck sein, denn: Ein Benutzer der Klasse Rechteck kann bei einem Rechteck die Seitenlängen unabhängig voneinander verändern. Bei einem Quadrat müsste das verändern einer Seitenlänge die andere automatisch mit ändern. Für einen Nutzer der Klasse Rechteck ist es unerwartet, dass sich beide Seitenlängen geändert haben.
Das ist ja das Standardbeispiel für liskov, trifft aber nicht den Punkt. Der häufigste Verstoß gegen Liskov ist wahrscheinlich das unerwartete Aufrufen von exceptions. Zu SOLID kommt auf jedenfall noch zu jedem Buchstaben ein Video. 😀
Verstehe ich, aber die Grundformulierung von Liskov ist: "Φ(x) sei eine beweisbare Eigenschaft für Objekte x vom Typ T. Dann soll Φ(y) wahr sein für Objekte y vom Typ S, wobei S ein Subtyp von T ist." Es besteht also ein Enger Zusammenhang zur Beweisbarkeit von Code/Algorithmen und z.B. dem Hoare-Kalkül. Wollte jetzt nicht abnerden, aber ich habe lange mit dem Kreis/Ellipse oder Quadrat/Rechteck- Beispiel gearbeitet in meiner Vorlesung und die Studierenden haben leider nicht das mitgenommen, was es eigentlich aussagen soll. Liskov ist nicht einfach und mache nochmal ein eigenes großes Video mit vielen Fällen dazu.
@@MemoryLeekDEalso, seid ihr sicher das verstanden zu haben? Das Prinzip sagt, das eine Unterklasse in der Lage sein muss, die Aufgaben ihrer Oberklasse zu übernehmen, ohne dass der Aufrufer davon Kenntnis hat. Klar beinhaltet das konsistente Ausnahmen, und das Vorbedingungen nicht verstärkt und Nachbedingungen nicht abschwächt werden dürfen. Aber Exceptions sind keine Bedingung für das Liskov Substitution Principle
Tolles Video, Daniel und Justin! Ich habe einige Jahre als Software-Entwickler gearbeitet und in meiner Ausbildung Clean Coding genau so kennengelernt, wie du es beschreibst. Wir hatten einen IT-Dozenten, der die weit verbreitete Auffassung des Themas eher kritisch betrachtet hat und uns zum eigenen Denken angeregt hat. Leider musste ich nach der Ausbildung feststellen, dass die Theorie sehr wenig mit der Realität zu tun hat. In der Praxis ging es dann doch eher immer sehr chaotisch zu, oft mussten Projekte einfach fertig werden, undzwar um jeden Preis. Da kannst du dir ja vorstellen, welche Priorität Konzepte wie Clean Coding hatten. Generell ging alles sehr unorganisiert zu, weit über die Software-Entwicklung hinaus. Ich bin überzeugt davon, dass eine Vielzahl an Unternehmen, besonders im regionalen Mittelstand, dringend Berater bräuchte, die erst mal grundlegend Ordnung schaffen. Erst, wenn die Organisationsstruktur aufgeräumt ist, kann man über Konzepte wie Clean Coding reden. Und, naja, so "verfaulen" dann viele Organisationen leider von innen heraus, weil sich nichts bewegt, was ich sehr schade finde. Seit einigen Monaten konzentriere ich mich zu 100 % auf meine eigenen Projekte als IT-Freiberufler. Ich kann mir meine Kunden und Projekte selber aussuchen und hab mein Portfolio um Consulting u. Business Analyse erweitert (da ich berufsbedingt Erfahrungen in den Bereichen gesammelt habe). Ich sage dir, ich habe lange nicht mehr so gut geschlafen, wie in dieser Zeit jetzt. Da wird einem erst bewusst, wie einen der Beruf runterziehen kann, wenn einem ein Stück weit die Hände gebunden waren. P.S.: Ich habe euren Kanal gerade erst entdeckt und die Qualität - sowohl inhaltlich als auch optisch - ist mega gut. Weiter so! Liebe Grüße - Niklas F.
Danke für die lieben Worte. Ich glaube es tut Unternehmen langfristig gut, wenn Entwickler bestimmte Qualitätsstandards im Software Engineering einfordern. Dazu müssen die Strukturen vorhanden sein oder entwickelt werden. Hierzu gibt es auch Untersuchungen, aber das Gesamtbild ist komplexer und sicherlich nicht eindeutig ...
Als guten Einstieg in die Grundlagen des Clean Code kann ich zwei Bücher empfehlen: "Code Complete" von Steve McConnell und "Writing Solid Code" von Steve Maguire
Sehr gutes Video! Das einzige, was ich mir wünsche würde, wären bei solchen Inhalten Codesnippets. Wenn man da sprachagnostisch bleiben möchte, in Pseudocode, ansonsten kann ich mir aber auch nicht vorstellen, dass jemand etwas gegen viel genutzte Sprachen wie Java, Python oder C für solche Erklärungssnippets haben könnte.
Oder eventuell C-Style Pseudocode, damit sich niemand benachteiligt fühlt, außer vielleicht Python-Entwickler. Und Haskell-Entwickler, aber die sind nicht so empfindlich... 😁
Sitze in nem relativ wichtigen Kunden Projekt, sehe das Video, erinnere mich an solche Projekte und werde sehnsüchtig. Sehe in mein aktuelles Projekt und möchte heulen.
Aaalso: die Unternehmen in denen ich gearbeitet habe, haben ganz andere Probleme als Clean Code. Da geht es erstmal darum Non-Catastrophic Code umzusetzen, z.b. leere Catch Blöcke, Duplicate Code, solche Dinge halt.
Ich glaube viele diese Probleme kommen von fehlendem Bewusstsein für solche Probleme und gerade das kann durch Interesse an Clean Code angegangen werden. Aber es gibt endlos viele Baustellen, auch im Management oder auch in der Kundensicht ...
doofe Frage aber habt ihr kein Sonarqube angebunden bzw. nicht in der Definition of Done? Sowas muss ganz klar in der DoD stehen. Ich verlange von allen Entwicklern die SonarIssues zu lösen, bevor sie ihr Ticket überhaupt zum Review bereit stellen. Machen sie das nicht, gibt eine auf den Deckel
Da habe ich mal die Frage, bezüglich deiner Behauptung, man könne Software-Qualität messen: In welcher Einheit werden diese Qualitätskriterien angegeben, und wie genau misst man sie?
Es gibt Tools, die Qualitäts-Kriterien messen können, bspw. die Testabdeckung in Prozent oder die Anteil der Funktionen, die mehr als 20 Zeilen haben. Letztlich müssen solche Messungen immer von Menschen beurteilt werden, denn auch eine Testabdeckung von 100% nutzt wenig, wenn die Tests nicht gut sind und eine Funktion mit 24 Zeilen kann trotzdem glasklar und für die Anforderungen optimal sein. Trotzdem können solche automatischen Messungen hilfreich sein, um Qualitätsmängel zu finden. Außerdem kann man natürlich auch die eigenen Kunden fragen, wie zufrieden sie sind oder Messen, wie häufig ein Programm während der Verwendung abstürzt oder messen in welcher Zeit es eine Aufgabe erfüllt. Die Software-Qualität direkt kann man wohl nicht messen, aber man kann mehr oder weniger sinnvolle Kriterien aufstellen, die sich messen lassen.
loc, Halstead-Metrik oder zyklomatische Komplexität. Allerdings sind das immer nur bedingt aufschlußreiche Teilbereiche von Software-Qualität aus der analytischen Qualitätssicherung.
@@foo0815 Das sehe ich auch so. Es sind Werkzeuge. Und wie jedes Werkzeug muss man sie mit Bedacht einsetzen. Sonst schaden sie mehr als sie nützen. Beispiel: Der Betriebswirt, der glaubt, den Fleiß von Entwicklern an der Anzahl der Codezeilen messen zu können (ich wünschte, ich hätte das erfunden).
Ja … einer meiner Professoren ist ein riesiger Fan von Uncle Bob und Clean Code. Allgemein muss ich sagen, es ist halt wie mit vielen Dingen im Leben, sich nur akribisch an etwas zu halten, nur weil es ein paar Gurus gesagt haben ist auch nicht immer das beste. Dabei muss man sagen, dass einige Prinzipien des Clean Codes wirklich mir dabei geholfen haben, besseren Code zu schreiben. Doch gerade bei dem Beispiel von Enten, ist mir wieder aufgefallen, warum ich Clean Code (und Objekt orientierte Programmierung) manchmal als störend empfinde. Was ist zum Beispiel, wenn das Projekt niemals Gummienten oder irgendeine Abänderung haben wird? Manchmal neigt man dann dazu, die Dinge viel abstrakter zu machen, als eigentlich nötig. So würde in ein paar Beispielen hier ja sogar das YAGNI Prinzip greifen. Somit beißen sich hier ein wenig die Regeln. Alles hat seinen Platz und Ort, ich glaube, das versuche ich damit zu sagen. There is there no silver bullet in software development :D Zum Video selbst: Super Video wirklich! In meiner Thesis habe ich mich mit Clean Code, XP und so weiter beschäftigt. Ich denke, ihr habt das echt gut aufbereitet, sodass auch Anfänger einen guten Einstieg in das Themengebiet finden, aber auch "ältere" Semester noch was dazu lernen können. Weiter so! :D
Kannte die Prinzipien schon, fand das Video aber gut als Refresher (ich habe oft ein Problem, die Begriffe mit ihren Bedeutungen zu matchen) und auch sehr gut erklärt.
Genau, das Beispiel dringt nicht zum Wesen des Problems vor. Die entscheidende Frage ist nämlich, ob Schwimmen auch für sich alleine sinnvoll vorstellbar ist. Wenn das ganze Programm sich überhaupt nur mit Enten und ihren Unterarten beschäftigt, dann ist das Interface ok so. Wenn auch Fische behandelt werden sollen, nicht. Wenn Fische "vielleicht später mal" behandelt werden sollen, gilt YAGNI, und im Ausnahmefall wird dann eben refactored. In Java ist das eine Kleinständerung an einer einzigen Stelle (im Enten-Interface).
@@utinah.6973 Zu bedenken wäre, daß viele Enten - bzw. Schwimmvögel generell - üblicherweise viele Meter tief tauchen können. Außerdem ist "schwimmen" im Deutschen schlecht interpretierbar. Eine Ente schwimmt auf dem Wasser. Fische im Wasser. Nur wenn sie tot sind schwimmen sie oben. Jaja.... Analogien sind irgendwie nicht gut. Hast recht 🤭
Tja, ein Grund für das Dilemma der Objektorientierten Programmierung, und warum Clean-Code in die Irre führt: Ich habe einfach keine Glaskugel, die ich aber bräuchte, um meine Abstraktionen passend und gut zu wählen. Und selten ist eine Überladung einer Multiplikation wirklich sinnvoller als eine dedizierte Funktion. Und das klare Bild habe ich erst "down the road". Und meine CPU kreuzt keine Blumen zwecks Vererbung, sie schaufelt und wandelt Daten von A nach B.
Meines Erachtens ist das genau das Problem von OOP. Es hat wenig mit der Realität zu tun. Egal, wie sehr man der Meinung ist, dass man eine gutes OOP-Design hat, der Beweis für das Gegenteil ist nie weit. Man muss sich einmal entscheiden, wie man die Dinge abbilden will. Bei jeder Entscheidung gilt: Sie kann falsch sein. Ich messe also eine Entscheidung daran, wie gut man sie ändern kann. Da sehe ich jetzt nicht, dass das Video zu dieser schwierigen Frage einen gewinnbringenden Beitrag leistet. In dem Video wird eben gesagt, die Dreifach-Interface-Vererbung wäre besser. Mir wäre mit so einer Aussage wenig geholfen. Solche Dinge kann man in einer komfortablen IDE auch sehr gut nachträglich ändern.
@@hrtmtbrng5968 Ich bin kein großer Fan von OOP, aber das Grundproblem sehe ich eher darin, dass man "pur" sein will und alles OOP sein muss. Man sollte eher das richtige Tool für jedes Problem wählen und auch in einem Projekt können durchaus Teile funktional und andere objektorientiert sein. Eben weil manche Probleme funktionaler Natur sind und andere sich gut als miteinander interagierende Aktoren darstellen lassen. Es macht auch keinen Sinn eine Sprache so zu designen genau ein Paradigma darzustellen (wie bspw. Java), ich brauch keine Klasse um eine mathematische Funktion herum. Wenn ich einen Namespace will schreib ich "namespace" hin. Und ganz genauso gibt es Stellen wo Clean Code Prinzipien Sinn machen (manche davon überall, wie "meaningful names") und andere Stellen wo andere Kriterien deutlich wichtiger sind. Leute denken einfach überall in schwarz-weiß und das ist das Hauptproblem. So gut wie alles ist Abwägungssache.
Variablennamen aus einem Buchstaben oder falsche Einrückungen haben doch gar nichts mit der Ausführungsgeschwindigkeit zu tun. Code, der hier sauber arbeitet ist exakt genauso schnell, aber er ist deutlich besser _lesbar_ und _verstehbar_ . Der Geschwindigkeitsnachteil kommt durch die vielen Abstraktionen.
Absolut! Schade, dass das wohl nicht richtig rübergekommen ist. Und ja, Abstractions sorgen für "langsameren" Code (also Laufzeit). In den allermeisten Fälle ist dies aber keiner sonderlich starke Anforderung an das Programm.
Ja, so lange nicht bis es zu langsam ist und dann hat man ein gewaltiges Problem. Ich selbst arbeite und schreibe HPC Code. Es werden ganz viele Fehler schon bei den grundlegenden Datenstrukturen gemacht, die bei Zeile eins eines eine Millionen Zeilen Programms definieren, dass das niemals schnell sein kann. Das sind leider Fehler die immer wieder passieren da die Leute immer weniger verstehen (wollen) wie Rechner funktionieren. Da hilft oft schon die O() Notation. Muss man aber eben sich seine Algorithmen/Code anschauen. Code Abstraktion und fancy Features aus objektorientierten Sprachen machen das nur noch schlimmer. Denn die Abstraktionen machen den Programmierern das Leben vielleicht einfacher, aber Compilern sehr viel schwieriger. Toll ist dann wenn man einen C++ Code hat, bei dem die Funktion +1 für 10% der Laufzeit verantwortlich ist, da die Funktion aufgrund der Größe des Projektes in ein anderes file gewandert ist und der Compiler nicht mehr erkennt, das man das doch inlinen könnte... Solche Dinge sind in buisness Code noch viel häufiger. Um Prinzip machen die Rechner ganz ganz viel Aufgaben zur Laufzeit, die man sich aus Faulheit beim programmieren gespart hat. Dadurch das CPUs aber nur noch bedingt schneller werden, fliegt das einem richtig auf die Füße wenn Performance dann doch gefragt wird. IMHO
Zum Thema Performance gilt die Daumenregel: 99% der Zeit wird in 1% des Codes verballert. D.h. ich muss nur 1% des Codes anfassen, um wirklich die Performance zu steigern bzw. ich kann mein Zeit damit verschwenden 99% des Codes zu optimieren und gewinne am Ende doch gar nichts dabei. Code, der so gut wie nie zur Ausführung kommt, muss aber nicht schnell sein oder sparsam mit Speicher umgehen, er muss vor allem gut lesbar, fehlerfrei und leicht wartbar sein. Ich bin z.B. immer wieder erstaunt, wie schnell manchmal Anwendungen sind, die eigentlich in Python geschrieben sind, obwohl Python wirklich keine schnelle Sprache ist. Aber der Grund ist einfach: das eine Prozent, wo es wirklich auf Performance ankommt, das ist gar nicht in Python geschrieben, das ist in C geschrieben und wird nur von Python aus aufgerufen.
Ich mochte den Ausdruck Wartbarkeit für Code nie. Datenbanken zum Beispiel brauchen Wartung, bei Code rede ich lieber von Änderbarkeit, weil er durch die Nutzung keine Wartung erforderlich macht.
@@jantack7186 Dann folge hier auf jedenfall, wir beginnen gerade eine Serie zu Clean Coding und Patterns in C# und danach auch in Python (als Beispiel für schwache Typisierung)
@@MemoryLeekDE Du hast nicht zufällig auch einen Literatur-Tipp für Clean Coding in PHP? Scheitere des öfteren daran, Entwurfsmuster von Java nach PHP (genauer WordPress) zu übertragen.
Das ist eine wirklich schöne Übersicht. Hilft mir sehr künftig beim BS-Bingo mithalten zu können 😁 Ich kämpfe zur Zeit mit "Legacy"-Code, in dem die Entities aus der Datenbank direkt ins View durchgeleitet werden 😨 Die daraus resulierenden null- und type-Exceptions fühlen sich an wie das "Hau den Maulwurf"-Spiel 😖
Absolut. Die Begriffe haben so tolle Bedeutungen und wurden von so klugen Menschen entwickelt. Die Herleitung und Anwendung des LSP unter anderem zusammen mit dem Hoare-Kalkül ist grandios. Und dann sitzt man in irgendeinem Meeting und jemand schleudert Begriffe einfach nur um sich wie Bonbons an Karneval ... 😖
Die Beschreibung des SRPs ist mir noch zu unklar. So wie ich das verstehe sollte eine Klasse die dem SRP entspricht nur Aufgrund drer Anforderung einer einheitlichen Gruppe von Akteuren zu ändern sein. Was auch durch das Schichtenmodell realisiert wird. Man hat z.B. einmal die Anforderung bzgl. der Darstellung und einmal bzgl. der Berechnung und dann noch bzgl. der Daten. Hier kann man sich vereinfacht vorstellen, das z.B Đarstellungsänderungen vom Marketing gewünscht werden. Die Berechnungsänderungen vom Controlling und die Datenänderungen von der IT. Dann teilt man das in drei Klassen/Objekte/Bereiche auf, so dass sich nichts vermischt.
Der kurze Überblick reicht sicherlich nicht um 100% zufrieden mit den Erklärungen zu sein. Das Single Responsibility Principle (SRP) und das Schichtenmodell sind zwar verwandt, verfolgen aber unterschiedliche Ziele und haben unterschiedliche Anwendungsbereiche. Lass mich dies näher erläutern: Das SRP bezieht sich in erster Linie auf Klassen in der Objektorientierten Programmierung, während die Schichtenarchitektur ja auf Grundlegende Strukturen bezieht. Die Konzepte sind verwandt, aber nicht gleich. Beide fallen unter das übergeordnete Prinzip "Seperation of Concerns" (SoC). Wir werden die SOLID Prinzipien nochmal jeweils in einem eigenen Video näher beleuchten und mit Code hinterlegen. Volle Industriebeispiele sind immer schwer hier unterbringen, aber vielleicht können wir ja mal eine Live-Refactoring Session überdenken.
Allein schon das Prinzip ich verändere nie etwas ist der größte quatsch. Jede Software kann mindestens 10x refactored und neu geschrieben werden, bis sie richtig gut ist. Wenn ich nie etwas ändern darf kann ich die Software nach ein paar Jahren einfach nur weg schmeißen. Wird dann immer langsamer, aber immerhin bauen wir keine neuen Fehler ein.
Danke für deinen Kommentar! Dein Punkt ist absolut verständlich. Das Open-Closed Principle (OCP) bedeutet, dass Klassen offen für Erweiterung, aber geschlossen für Modifikation sein sollten. Das heißt nicht, dass man nie etwas ändern darf, sondern dass man neue Funktionalitäten durch Erweiterungen hinzufügt, um stabile Codebasen zu bewahren und das Risiko neuer Fehler zu minimieren. Refactoring bleibt wichtig, um die Qualität der Software zu verbessern. Es geht darum, den Code sauberer und effizienter zu machen und langfristig unnötige Komplexität zu vermeiden, die die Software langsamer machen könnte. Es ist sinnvoll, sich mit diesen Prinzipien auseinanderzusetzen, weil es immer eine Balance zwischen "technical debt" und sauberer Programmierung geben muss. Clean Coding zu lernen hat viel damit zu tun, das richtige Mindset zu entwickeln. Daher sollte man hier nicht dogmatisch sein. Deine Perspektive zeigt, wie wichtig kontinuierliche Verbesserung im Software-Engineering ist.
Sehr schönes Video vielen Dank. Bei dem "warum" hätte ich aber mehr zum Thema wartbarkeit erwartet. Im Video gehst Du gar nicht so richtig auf die Entwicklung im Team ein. Denn was bringt mir die perfekt Programmierte Klasse, die nur von einem Programmierer gewartet werden kann? Die Aufteilung nach den Prinzipien hilft dann bzw. führt zu besserer Wartbarkeit. Zusätzlich fehlt auch der Bereich Unit Tests. Automatisierte Tests sind ein sehr entscheidender Teil von Clean Code.Hier kann ein neuer Entwickler eine Klasse anpassen ohne Angst zu haben etwas kaputt zu machen. D.h. Team-Coding sollte auch Clean-Coding sein.
Absolut. In meinen Vorlesungen ist es einer der gedanklichen Shifts, den Studierende hinbekommen müssen. Oft starten gerade Anfänger und Einzelkämpfer mit einem falschen Bild davon, wie Software entwickelt wird. Wenn ich alleine den Code mit viel Redbull in 3 Nächten weghacken, weil es eine Eingebung meinerseits oder eine Aufgabe aus der Schule ist, brauche ich wahrscheinlich keinen Clean Code.
Hier geht es ja gar nicht um clean Code. Clean Code hat nix mit SOLID zu tun. Es geht um die Prinzipien von Robert Martin. Ich glaube ihr habt selber nicht verstanden, was clean Code ist und das zitierte Video auch nicht kapiert. 😂
Danke für deinen Kommentar! "Clean Code" als Begriff und SOLID sind eng miteinander verbunden und sind beides Konzepte die von Robert C. Martin popularisiert wurden. Robert C. Martin hat die SOLID-Prinzipien, die aus bereits bestehenden Prinzipien stammen, systematisiert und durch seine Publikationen bekannt gemacht. Die meisten dieser Prinzipien wurden vorher entwickelt und separat in den 1980er Jahren veröffentlicht. Wenn du andere Infos hast freue ich mich dazu zulernen. Natürlich wie immer mit einem respektvollen Umgang :) - Daniel
@@MemoryLeekDE Lieber Daniel, so mega eng scheinen die Konzepte nicht verwand zu sein, wenn Uncle Bob in seinem Cean Code Buch die SOID-Prinzipien nur in einem Nebensatz kurz erwähnt oder? Du machst dann ein Video: "Clean Coding: Das verstehen alle falsch!", sprichst ausführlich über: SOLID. Nicht über Polymorphismus, die bösen switch und if Statements, Testbarkeit, kleine Funktionen, diesdasjenes In dem sehr guten, von dir verlinkten Video '"Clean" Code, Horrible Performance' geht es dann komischerweise genau um diese Prinzipien, nicht um SOLID und Entwurfsmuster, wie von dir am Anfang erklärt. Also nochmal und mit viel Respekt: Das Thema Clean Code wurde im Video verfehlt.
@@g2h5j3 Man muss hier sicherlich nochmal zwischen Nebenläufigkeit und Parallelität und zwischen Shared und Distributed Architekturen unterschieden. Könnte mehr als ein Video werden ... Auf die Programmiersprachen gehen wir dann direkt auch ein.
Das Enten-Beispiel ist meiner Meinung nach richtig schlecht. Zunächst ist eine Gummiente, weder ein Tier noch eine Ente. Der Programmierer sollte gar nicht erst auf die Idee kommen zu versuchen das zu implementieren. Aber ja, Fehler sind menschlich und schon viel Unsinn hier gesehen.
Sehr gutes Video für diejenigen, die wirklich gute Programmierer werden wollen und bereit sind, sich tiefgründig mit dem Thema zu befassen. Die Realität sieht leider anders aus. Code-Refactoring wird selten durchgeführt. Die Notwendigkeit dafür wird weder erkannt, noch eingesehen. Das kann man an etlichen Open-Source-Projekten direkt sehen. Meine Meinung: Wenn man eine Programmiermethode verwendet, die die Einhaltung in der Praxis so schwer zu etablierenden Prinzipien verlangt, dann ist an der Programmiermethode etwas falsch. Wenn man ehrlich ist, hat sich OOP in der Praxis gar nicht bewährt. Wer dennoch an OOP festhalten will, braucht derart komplizierte Prinzipien. Aber wenn eine Methode ständiges Nacharbeiten in Form von Refactoring verlangt und derart schwer zu erlernen ist, dann ist die Methode nicht für den professionellen Einsatz geeignet.
Ich bin nur zufällig auf dein Video gestoßen und muss sagen, dass Clean Code nur da angewandt werden soll, wo er auch Sinn macht. Ich habe es im ABAP-Umfeld erlebt: Die SAP bietet sogenannte Funktionsbausteine an. Hier gibt man ein Parameter rein und bekommt ein Ergebnis zurück. Das ist freigegeben und getestet. Nun kam ein findiger Entwickler auf die Idee, diesen Funktionsbaustein in eine Klasse zu packen, um damit minimale Parameter an den Methoden zu erreichen - also ein einfacher GETTER. Für jeden Import-Parameter des Funktionsbaustein gibt es eine Methode. Hier wurde ca. 10 Methoden ausgeprägt, weil genau diese gebraucht werden. Der Funktionsbaustein kann aber mit ca. 250 Ausprägungen von Importparametern gerufen werden. Die Klasse müsste also 250 Methoden haben. Im Ergebnis wird also VIEL, sehr VIEL Quellcode erzeugt, nur um bestehendes Coding auf neue Herangehensweise zu hiefen.
Wer ein Video über Clean Code macht, muss auch ein Video über Clean Architecture machen. ;) Ansonsten mehr zu Dependency Injection und IOC-Containern. Und was man tun kann, wenn Dependency Injection Geheimnisprinzip, Einhaltung von Klasseninvarianten oder Information-Expert-Verantwortlichkeiten entgegen steht.
Dieses Beispiel mit der Ente und der Gummiente habe ich schon oft gehört. Aber ist das Problem dabei nicht ein ganz anderes? Wenn man eine Ente mit den Interfaces Fliegen, Fressen und Schwimmen implementieren will, dann geht es in aller Regel um ein Tier aus der Familie der Entenvögel, und dann gehören diese Funktionen immer zusammen. Eine Gummiente würde wohl eher ein Spielzeug implementieren, als ein Tier. Man würde ja auch eine "Citroën 2CV" Klasse nicht von der Enten-Klasse erben lassen, nur weil man das Auto auch "Ente" nennt.
Nimm das nicht so wörtlich. Es geht bei dem Beispiel eher darum zu zeigen, dass eine Klasse nicht unbedingt alle im Interface definierten Methoden implementieren muss. Hier wäre es Aufgabe des Architekten zu definieren, was in einem solchen Fall passieren soll. Wir haben z.B. eine WinForms-Anwendung, da werden die Menüpunkte einfach ausgegraut, damit die leeren Methoden nicht aufgerufen werden. Zeigt dem Anwender: Grundsätzlich könnte man die Methoden aufrufen, aber nicht mit der aktuellen Implementierung des Interfaces. Mit unserer Anwendung kann man z.B bequem durchs AD navigieren zwischen Anwendern und Gruppen. So macht die Methode Gruppenmitglieder():List auf eine Gruppe Sinn, auf einen User nicht (würde leere Liste zurückgeben). Durchs Ausgrauen im Menü wird klar: Geht nicht. Der Hintergrund war, dass wir keine zwei Dialoge implementieren wollten, die nahezu identisch sind (DRY). Stattdessen definieren zwei "Strategie"-Objekte mit der selben Schnittstelle, was der Dialog und das Kontextmenü anzeigt.
Das Interface Segregation principle ist meiner Meinung nach am häufigsten falsch erklärt. Natürlich ist ein Grund die Interfaces klein zu halten, dass man den Entwickler der Realisierung nicht "zwingen" sollte, bestimmte Methoden zu implementieren, obwohl sie gar nicht gebraucht werden. Dies folgt aber direkt aus SRP und LSP. Das ISP hingegen sagt "no code should be forced to depend on methods it does not use", sprich, Interfaces, die ich via dependency injection verwende, sollten möglichst klein sein. Anstatt IDuck, sollte ich lieber IFlyable und IQuackable injecten. Dann muss ich z.B in einem möglichen "FlyController" nur noch IFlyable injecten. Wenn sich nun IQuackable oder meine Duck-Implementierung ändert, muss ich im Flycontroller nichts ändern, ich muss ihn sogar nicht mal neu kompilieren.
Die Regel bei Variablenamen ist bei mir z.B.: Je weiter der Scope einer Variable, desto besser muss ihr Name sein. In einer for-Schleife mit nur einer Zeile Code, darf man durchaus "i" für den Index nutzen. Bei 3 Zeilen Code, wäre vielleicht "idx" schon angebracht. Bei 20 Zeilen Code würde ich auf "index" zurück greifen. Aber bei einer Klassenvariable, reicht index schon nicht mehr aus, weil "Was für ein Index? Wofür ist der Index gut?"
Warum drei verschiedene Namen für ein und das selbe? Außerdem sollte man Indices ohnehin vermeiden und Iteratoren verwenden. Direkt über die Objekte iterieren statt Indices oder Pointer. Beschreibende Variablennamen sind häufig ein Zeichen fehlender Abstraktion. Wenn ich in eine CustomerListe einen Customer unter der Bedingung, dass er älter als 18 Jahre ist, einfügen will, dieselbe Funktion aber auch Tiere in eine Tierliste einfügen könnte, wenn sie mehr als 1,8 kg wiegen, dann haben Variablennamen wie Customer und CustomerListe nichts in dieser Funktion zu suchen, sondern E wird in L unter C eingefügt.
@@frankklemm1471 Es sind nicht drei verschiedene, es ist nur genau einer, aber welchen davon ich wählen würde, hängt eben vom Code ab. Warum? Weil mir ein unnötig langer Name in einer oder drei Zeilen Code kein Vorteil bringt (wer sich einen Namen nicht über diese Distanz merken kann, der ist als Programmiere IMHO ungeeignet; gibt auch andere schöne Berufe, wo man sich nichts merken muss), aber mehr Code tippen und mehr Code lesen zu müssen, bringt mir Nachteile, denn meine Tipp- und Lesegeschwindigkeit ist endlich. Und eine Programmiersprache wie C hat gar keine Iteratoren, außerdem wer hat jemals davon gesprochen, dass ich hier etwas iteriere? Wie du z.B. quicksort mit Iteratoren implementierst, das zeigst du mir mal. Oder vielleicht möchte ich in einer Matrix nur ein paar Zeilen lesen und niemand nutzt in Matrix-Code iteratoren. Alleine was du hier also für Annahmen triffst über Code, von dem du nicht mal weißt, was der tut, ist haarsträubend.
Programmiere schon > 10 Jahre. Clean code ist wie mit Fahrschule und Autofahren bzw. Schule und das Leben. Die Clean Code Prinzipien sind die Fahrschule/Schule. Praktikablen und belastbaren clean code lernt man dann nach der Fahrschule bzw im richtigen Leben. Richtigen clean code erreicht man meist nur wenn man Programmieren als Hobby betreibt.
Warum erreicht man richtigen CleanCode meist nur, wenn man das Programmieren als Hobby betreibt? Wenn man weiß, wie ein Code funktioniert, dann ist das jedoch noch kein sauberer Code, sondern einfach nur ein Insiderwissen. Wie kann man einen praktikablen und belastbaren CleanCode nach der Fahrschule bzw. im richtigen Leben lernen, wenn schon in der "Fahrschule" kein oder wenig richtiger CleanCode vermittelt und gelernt wird? Bestenfalls nur die Hälfte zu lernen und vermittelt zu bekommen, empfinde ich nicht als einen ordentlichen Lernprozess. Ja, als Anfänger muss ich klein anfangen, aber dennoch das große Ganze verstehen und begreifen können - ohne, dass große Teile einfach weggelassen oder ignoriert werden.
#1:00 -- ich mag ja die Lorem-Ipsum-Überschrift der Stichpunkte .. zeigt wie sehr die benannten Clean-Coding-Kriterien auf dieses Video angewendet wurde 😉 Eine schöne Übersicht, auch wenn der Titel nicht wirklich begründet wurde.
Ich bin gerade zufällig auf dieses Video gestoßen und bin, gerade auch vom Fazit, schon mal begeistert. Ein Abo ist selbstverständlich und bringt mir hoffentlich mehr als euch! 😁 Einziger Kritikpunkt: ich wollte gerade auf eure Website schauen und da kommt nur eine Standard-Seite von Strato, dass die Domain reserviert ist.
@@MemoryLeekDE Sinnvoller wäre wohl gewesen die Seite erst zu verlinken, wenn sie da ist! Wie gesagt: no offense! Macht weiter so! Ich bin wirklich absolut froh, dass es so hochklassigen Content gibt. Und bei der Qualität werdet ihr sicher durch die Decke gehen! 🙂
In dem Entenbeispiel ist ein Fehler. Eine Wildente kann nicht von Anfang an fliegen. Entenküken müssen das erstmal lernen. Du kannst aber den Typ deiner Objekte nicht ändern, nur weil sich ihre Fähigkeiten ändern. Daher scheint mir der Interface-Ansatz nicht der richtige zu sein. Wenn Du solche Dinge nicht berücksichtigen willst, dann frage ich mich, warum Du überhaupt OOP verwendest. Wenn Dir von Anfang an klar ist, was eine Ente kann, dann kannst Du auch einfach einen Typ Tier definieren und Prozeduren zum Schwimmen, Essen und Fliegen und Dich darauf festlegen, welche Du aufrufst. Dass es ein Vorteil ist, wenn Du in Deiner Programmiersprache ausdrückst, dass nur fliegende schwimmende essende Tiere fliegen, schwimmen und essen können, bezweifele ich. Niemand würde versuchen, einen Igel fliegen zu lassen. Welchen Vorteil soll es bringen, wenn man an den Igel dranschreibt, dass er nur essen kann? Damit es jeder weiß und die IDE dich davor schützen kann, dass Du ihn nicht fliegen lässt? Aber ein Seeigel kann schwimmen.
@@MrCutsandCards Essen zu können ist aber eine beliebige Eigenschaft. Wie würdest Du denn ein Array anlegen mit allen Vögeln, die blaue Schwanzfedern haben? Wären vegetarische Tiere auch eine eigene Klasse? Oder vegetarische Vögel? Oder überwiegend carnivorische Huftiere. Das komische an OOP ist, dass man immer versucht, irgendwelche Kategorien zu bilden, weil man denkt, dass man vielleicht mal irgendein spezielles Array o.Ä. braucht. Aber ob man das dann echt braucht, ist unklar. Und wenn, dann kann man auch einfach ein Array vom Typ Tiere nehmen. Das macht alles viel einfacher.
