Warum brauchen wir so viele Klassen in Designmustern?

Ich bin ein Junior-Entwickler unter Senioren und kämpfe oft mit dem Verstehen ihres Denkens und Denkens.

Ich lese Domänengesteuertes Design (DDD) und kann nicht verstehen, warum wir dies tun müssen Erstellen Sie so viele Klassen. Wenn wir dieser Methode zum Entwerfen von Software folgen, erhalten wir 20 bis 30 Klassen, die durch höchstens zwei Dateien und 3 bis 4 Funktionen ersetzt werden können. Ja, das könnte unordentlich sein, aber es ist viel einfacher zu warten und lesbarer.

Immer wenn ich sehen möchte, was eine Art EntityTransformationServiceImpl tut, muss ich viele Klassen, Interfaces, deren Funktionsaufrufe, Konstruktoren, ihre Erstellung usw. verfolgen.

Einfache mathematik:

  • 60 Zeilen Dummy-Code vs. 10 Klassen X 10 (Nehmen wir an, wir haben völlig andere Logiken) = 600 Zeilen unordentlichen Code vs. 100 Klassen + einige weitere zum Einschließen und Verwalten; Vergessen Sie nicht, Abhängigkeitsinjektion hinzuzufügen.
  • 600 Zeilen unordentlichen Code = einen Tag lesen
  • 100 Unterrichtsstunden = eine Woche, vergessen Sie immer noch, was Sie wann tun,

Jeder sagt, es sei leicht zu pflegen, aber wofür? Jedes Mal, wenn Sie neue Funktionen hinzufügen, fügen Sie fünf weitere Klassen mit Fabriken, Entitäten, Services und Werten hinzu. Ich habe das Gefühl, dass sich dieser Code viel langsamer bewegt als unordentlicher Code.

Nehmen wir an, wenn Sie in einem Monat 50 KB LOC-Code schreiben, erfordert die DDD-Sache viele Überprüfungen und Änderungen (ich habe nichts dagegen, Tests in beiden Fällen durchzuführen). Eine einfache Zugabe kann eine Woche dauern, wenn nicht mehr.

Innerhalb eines Jahres schreiben Sie viel chaotischen Code und können ihn sogar mehrmals umschreiben, aber mit dem DDD-Stil haben Sie immer noch nicht genügend Funktionen, um mit chaotischem Code zu konkurrieren.

Bitte erkläre. Warum brauchen wir diesen DDD-Stil und viele Muster?

UPD 1: I received so many great answers, can you guys please add comment somewhere or edit your answer with the link for reading list (not sure from which to start, DDD, Design Patterns, UML, Code Complete, Refactoring, Pragmatic ,... so many good books), of course with sequence, so that I can also start understanding and become senior as some of you do.

198
@ user1318496 Dieses ist ein Duplikat der obigen Frage. Sie wissen nur nicht, was Sie eigentlich fragen. Die Essenz Ihrer Frage hat wirklich nichts mit OO zu tun, im Gegensatz zu funktionaler Programmierung oder Entwurfsmustern und allem, was mit Organisation zu tun hat. Die Frage, auf die Sie tatsächlich eine Antwort wünschen, lautet: "Warum Code in verschiedene Atomeinheiten aufteilen?". Obwohl viele Entwickler die Antwort darauf selbstverständlich finden, ist dies eine sehr gültige Frage. Eine, mit der viele Entwickler in einer anderen Form zu kämpfen haben, während sie gerade erst anfangen.
hinzugefügt der Autor Vassilis, Quelle
"Ja, das könnte unordentlich sein, aber es ist viel einfacher zu pflegen und lesbarer." Wenn es unordentlich ist, wie kann es lesbar und wartbar sein?
hinzugefügt der Autor Bigballs, Quelle
@Jared: "Was ist einfacher zu testen?": Wie immer hängt das von der Art des Tests ab. Wenn Sie über 100 triviale Klassen verfügen und das gesamte Systemverhalten darin besteht, wie sie miteinander verknüpft sind, ist das resultierende System im Allgemeinen nicht einfacher zu schreiben, da Integration und QS-Tests einfacher sind als der naive Monolith. Sie haben mehr als 100 Einzeltests, die behaupten, "Sie haben Ihr Design nicht geändert", aber was ist dann? Das OP kann übertrieben sein und/oder der Code ist möglicherweise in Ordnung, aber wenn das Verhältnis wirklich 1 Klasse pro 6 Zeilen naiven Codes ist, um dasselbe Problem zu lösen, gibt es Gründe zu prüfen, ob es überentwickelt ist :-)
hinzugefügt der Autor TraumaPony, Quelle
Und mit "das gleiche Problem lösen" meine ich natürlich vollständig gelöst. Dies ist ein anderer Bereich, den das OP möglicherweise nicht gesehen hat, was die Autoren dieser Codebasis sehen. 600 Codezeilen, die meistens funktionieren, sind nicht dasselbe wie 100 Klassen, die in einem Rahmen stehen, der extern nützliche Sätze beweist, mit denen Sie feststellen können, dass der Code tatsächlich funktioniert !
hinzugefügt der Autor TraumaPony, Quelle
@EricLippert: Wenn der Code mit den 100 Klassen Funktionen aufweist, die dem Benutzer der Software leicht erklärt werden können, der naive Code nicht, dann ist das eine großartige Analogie. Ich denke, der Unterschied zwischen einem Loch in der Wand und einem verglasten Fenster ist ziemlich einfach zu klassifizieren als "die naive Lösung ist nicht wirklich eine Lösung, da sie unseren tatsächlichen Benutzeranforderungen nicht genügt". Wenn also der zusammengehackte Code an einem Tag funktioniert, aber nicht in den Software-Stack integriert werden kann, in dem Ihre eigentlichen Dienste für Benutzer ausgeführt werden, wäre dies ein Beispiel für ein schlagendes Argument für das Schreiben weiterer Klassen.
hinzugefügt der Autor TraumaPony, Quelle
@Jared: Du hast bereits darauf gesetzt, dass die 100 Klassen leichter zu testen sind als der Monolith. Ich habe nur auf diese Behauptung geantwortet. Die einfache Änderung des Codes ist ein ganz anderes Argument gegen Monolithen :-)
hinzugefügt der Autor TraumaPony, Quelle
Es ist zu beachten, dass OOP kein universelles bestes Werkzeug ist. Daher kann die Lösung jedes (Teil) des Problems durch Hinzufügen weiterer Klassen, insbesondere mit Vererbung, zu schlechten, unnötig komplizierten Konstruktionen führen. Das Problem ist, dass die Erstellung eines guten Designs Zeit und einen erfahrenen Entwickler erfordert, und beide sind teuer. Mit einem chaotischen Design ist das Geschäft oft in Ordnung, wenn es gerade funktioniert .
hinzugefügt der Autor Rorick, Quelle
Sie tun es nicht, es sei denn, Sie machen Java. Wenn Sie nur Java haben, sieht alles aus wie eine Klasse.
hinzugefügt der Autor Krzysztof Klimonda, Quelle
Vereinfacht gesagt, ist es schwieriger und dauert länger, eleganten Code zu schreiben, sodass sich die Leute mit unzusammenhängendem, aber stark strukturiertem Code zufrieden geben.
hinzugefügt der Autor Mr Rogers, Quelle
Vielleicht sollte man überarbeiten eigene Überzeugungen
hinzugefügt der Autor innaM, Quelle
@Polygnome: Ich wollte genau den gleichen Kommentar eingeben. Ein weiterer auserlesener Kommentar, der für junge Entwickler charakteristisch ist, ist: "Ich habe das Gefühl, dass sich diese Art von Code viel langsamer als unordentlicher Code bewegt." Es ist nicht gut, so schnell wie möglich zu rennen, wenn man die Hälfte der Zeit damit verbringt, in Wände zu rennen! Langsam ist glatt, glatt ist schnell.
hinzugefügt der Autor CodeCharming, Quelle
Diese Frage ist eher wie die Frage: "Warum brauchen wir so viele Teile, um ein Fenster zu bauen? Da gibt es diesen ganzen Jargon mit Schärpen und Schärpenschnüren und doppelt aufgehängtem und dreifach verglastem Flügel und es ist zu verwirrend. Wenn ich durch eine Wand sehen möchte, muss ich nur bohren, ein Loch in die Wand bohren, fertig. Warum wollen die Schaufensterbauer alles so kompliziert machen, wenn ich es so einfach machen kann? "
hinzugefügt der Autor CodeCharming, Quelle
Ich fühle mich in Klassen im Allgemeinen genauso wie Benutzer1318496. Vielleicht ist es mehr eine persönliche Vorliebe als alles andere.
hinzugefügt der Autor Graham, Quelle
@Graham Language-Funktionen sind bis zu einem gewissen Grad persönliche Vorlieben, aber das ist orthogonal zu dieser Frage. Funktionscode kann genauso gut geschrieben werden, dass er leicht erstellt und geändert werden kann.
hinzugefügt der Autor R. Schmitz, Quelle
@ 9000 Ich glaube, das, worüber du sprichst, heißt COP - "Class-Oriented Programming". Wenn Sie Klassen hinzufügen, ohne sich über Objekte zu beklagen, machen Sie keine OOP ...
hinzugefügt der Autor R. Schmitz, Quelle
Wir brauchen sie wirklich nicht ...
hinzugefügt der Autor Vector, Quelle
Bin ich der Einzige, der der Meinung ist, dass die Verwendung von 20-30 Klassen mit EntityTransformationServiceImpl s zur Lösung eines einfachen Problems ein starkes Engineering darstellt? Ich vermute, Sie beziehen sich auf Java, dessen Kultur darin besteht, Designmuster auf Designmuster zu werfen, bis die Codebasis unverständlich ist ...
hinzugefügt der Autor Solomonoff's Secret, Quelle
Ich denke, es gibt hier eine gute Frage, die sich jedoch hinter Übertreibung und Frustration verbirgt. @ user1318496, könnten Sie von der Neuformulierung Ihrer Frage profitieren.
hinzugefügt der Autor Warpspace, Quelle
@jamesqf Vielleicht sehen Sie es als religiöse Bekehrung. Ich sehe es als eine Funktion des Typs Religion -> Religion .
hinzugefügt der Autor Chad, Quelle
Einige dieser Antworten und Kommentare sprechen sich aneinander vorbei. Ich denke, es könnte hilfreich sein, über zwei verschiedene Fragen nachzudenken, z. "Warum DDD/design-pattern/etc anstelle von" einfachem "Code im Allgemeinen " (Testbarkeit, Entkopplung usw.) und "Warum" diese spezielle Codebase verwenden so viel mehr Klassen, als ich erwarten würde? " (überkonstruierte, sprachspezifische Problemumgehungen (z. B. keine Lambdas), veralteter Stil (z. B. Java verfügt jetzt über Lambdas), Frachtkultivierung, Tech-Schulden usw.)
hinzugefügt der Autor Warbo, Quelle
Ich finde Ihre Mathematik in Bezug auf Codezeilen und ihre Verständnislosigkeit ziemlich komisch. Ich möchte wirklich eine ausführliche Beschreibung Ihrer Argumente hinter den von Ihnen verwendeten Zahlen.
hinzugefügt der Autor Euphoric, Quelle
Msgstr "600 Zeilen unordentlichen Code lesen = ein Tag". Das ist falsch ... Die Zeit, die ich zum Lesen einer Klasse brauche, nimmt exponentiell zu, werden alle Verzweigungen und Verzweigungen falsch sein usw. Bei 600 Zeilen bin ich am Rand meiner Komfortzone. Bei 1000 brauche ich normalerweise etwa einen Monat, um die Klasse vollständig zu verstehen.
hinzugefügt der Autor ArTs, Quelle
Der F22-Raptor wurde nicht gebaut, indem ein IKEA-Lager mit Halterungen in eine Flugzeugform gegossen wurde.
hinzugefügt der Autor ArTs, Quelle
Sind diese Klassenkonzepte in Ihrer Domäne vorhanden? Wenn nein, warum gibt es sie? Wenn ja, dann haben sie Geschäftswert, richtig? Welche Flexibilität verlieren Sie in der Zukunft, wenn Sie 600 Zeilen unordentlichen Code gegenüber 20-30 Klassen schreiben, die Domänenkonzepte darstellen?
hinzugefügt der Autor Rob Crawford, Quelle
OOP ist oft ein Anti-Pattern und reine OOP ist fast immer ein Anti-Pattern. OOP neigt dazu, an allen möglichen Stellen im Code zu verbluten, insbesondere bei der Testbarkeit. Bei den Design-Mustern wird der Hammer (OOP) verwendet, um all diese Nägel einzubringen, die Sie bei übermäßigem OOP-Einsatz verteilt haben. Wenn Sie über eine Klasse mit dem Namen Provider , Entity oder Processor verfügen, verwenden Sie wahrscheinlich OOP, aber Sie können sicherlich viele Leute finden die herausgefunden haben, wie man diesen Nagel OOP macht.
hinzugefügt der Autor Rich Remer, Quelle
Beachten Sie, dass diese spezielle Art, Code zu schreiben, kein Problem mit Mustern ist, sondern mit den Leuten, die den Code schreiben. Sie können eine umfangreiche Software mit vielen Mustern und vielleicht 40 oder 50 Klassen schreiben. einfach. Aber wenn Sie die Dinge überschneiden ... nun, dann erhalten Sie 20 Klassen für etwas, das mit 3 Klassen oder mit 4 bis 5 prozeduralen Funktionen hätte gemacht werden können. Die wichtigste Fähigkeit ist, zu erkennen, wenn eine Klasse zu groß wird, um sie zu brechen, damit sie nicht zu einer Gottklasse wird.
hinzugefügt der Autor marstato, Quelle
In der Verteidigung von OPs ist ein gutes Beispiel für das, worauf er sich beziehen könnte, das einfache Umschalten von 3 oder 4 Zuständen mit niedrigem Wert durch ein Zustandsmuster überall. Ich habe gesehen, dass dies passiert, und das Ergebnis kann tatsächlich hundert Klassen anstelle von hundert Zeilen Code sein. Auch die Wartung ist gefährdet.
hinzugefügt der Autor Sentinel, Quelle
Ich kann nicht glauben, dass niemand das Single-Responsibility-Prinzip (das, wenn Sie es befolgen, zur Erzeugung zahlreicher Klassen führt) und die SOLID-Prinzipien im Allgemeinen erwähnt hat.
hinzugefügt der Autor sizzlecookie, Quelle
@ user1318496 - Sie brauchen sich keine Sorgen zu machen. Es gibt viele erfolgreiche Unternehmen, die Ihre Meinung teilen. Und sie stellen die ganze Zeit ein, weil sie mehr Entwickler brauchen, um Code zu verwalten, der schnell geschrieben wurde .. :)
hinzugefügt der Autor Fabio, Quelle
Vor Jahrzehnten habe ich in einem Geschäft gearbeitet, in dem wir ein Upgrade von DOS 2.0 auf DOS 3.0 durchgeführt haben. In der ersten Version gab es nur ein einziges Verzeichnis, in dem sich alles befand. In letzteren wurden Unterordner eingeführt. Mein Chef fragte: "Warum brauchen wir all diese Unterordner? Warum kann ich nicht alles in einem Ordner ablegen, damit ich weiß, wo ich ihn finden kann?" Gute Zeiten. :)
hinzugefügt der Autor David Lang, Quelle
Bei Entwurfsmustern geht es nicht nur um Wartbarkeit, sondern auch um Wiederverwendbarkeit.
hinzugefügt der Autor Randy E, Quelle
Auf die Gefahr, auf die Zehen zu treten, weil Ihre Sprache scheiße ist. Nehmen Sie das nicht für mehr als es ist: Eine saugende Sprache ist aus verschiedenen Gründen oft die richtige technische Wahl, aber das macht sie nicht lästig. Für Ihre eigentliche Frage ist Korrektheit wichtiger als Lesbarkeit. Oder um es etwas anders auszudrücken: Die Lesbarkeit ist insofern von Bedeutung, als sie ein Nachdenken über die Richtigkeit ermöglicht. Was ist leichter zu testen, Ihre 100 Klassen oder Ihre monolithische Gottheit? Ich wette 100 einfache Klassen.
hinzugefügt der Autor Sujan, Quelle
@SteveJessop Ja, das Testen des -Systems ist in beiden Fällen gleichermaßen komplex. Vielleicht sogar mehr im Fall mehrerer Klassen. Der Unterschied ist folgender: Mit dem Monolithen kann es leichter sein, zu finden, wo eine Änderung vorgenommen werden muss, und es gibt möglicherweise unbegrenzte Zeit, um das Problem zu beheben, das möglicherweise durch die Herstellung zerstört wird. Das Finden des korrekten Codeteils in der aufgeteilten Codebasis ist schwieriger, aber eine bekannte Menge, und die Änderung ist trivial. Ich bin lieber zuversichtlich als würfeln, aber YMMV und eine Größe passen nicht alle. Für weniger als 10.000 Zeilen könnte ich den Monolithen bevorzugen. Könnte sein.
hinzugefügt der Autor Sujan, Quelle
@Theodoros Chatzigiannakis: Das ist nur eine religiöse Bekehrung. Das Problem ist die unbewusste Anbetung einer Softwareentwicklungsmethodik. Sie ändern nur die Gottheit, behalten aber die unbeirrte Einhaltung von Ritualen bei.
hinzugefügt der Autor Ruks, Quelle
@Rob Crawford: Re "... 600 Zeilen unordentlichen Code vs. 20-30 Klassen ...", Sie haben hier zwei nicht zusammenhängende Dinge. Es ist durchaus möglich, 600 Zeilen klarer, gut kommentierter Code zu schreiben, genauso wie es möglich ist, dies in 20 bis 30 unordentliche Klassen zu konvertieren.
hinzugefügt der Autor Ruks, Quelle

10 Antworten

Dies ist ein Optimierungsproblem

Ein guter Ingenieur versteht, dass ein Optimierungsproblem ohne Ziel bedeutungslos ist. Sie können nicht nur optimieren, Sie müssen für etwas optimieren. Zu Ihren Compiler-Optionen gehören beispielsweise die Optimierung der Geschwindigkeit und die Optimierung der Codegröße. Dies sind manchmal gegensätzliche Ziele.

Ich sage meiner Frau gerne, dass mein Schreibtisch für die Optimierung optimiert ist. Es ist nur ein Haufen und es ist sehr einfach, Sachen hinzuzufügen. Meine Frau würde es vorziehen, wenn ich für den Abruf optimieren würde, d. H. Meine Sachen ein bisschen organisiert habe, damit ich Dinge finden kann. Dies macht es natürlich schwieriger, hinzuzufügen.

Software ist der gleiche Weg. Sie können sicherlich für die Produkterstellung optimieren - generieren Sie so schnell wie möglich eine Tonne monolithischen Code , ohne sich darum zu kümmern, es zu organisieren. Wie Sie bereits bemerkt haben, kann dies sehr, sehr schnell sein. Die Alternative besteht darin, die Wartung für die Wartung zu optimieren - die Erstellung wird dadurch schwieriger, aber Änderungen werden einfacher oder weniger riskant. Das ist der Zweck von strukturiertem Code.

Ich würde vorschlagen, dass ein erfolgreiches Softwareprodukt nur einmal erstellt, aber viele, viele Male geändert wird. Erfahrene Ingenieure haben gesehen, dass unstrukturierte Codebasen ein Eigenleben entwickeln und zu Produkten werden, die an Größe und Komplexität zunehmen, bis kleine Änderungen nur sehr schwer durchführbar sind, ohne ein großes Risiko einzugehen. Wenn der Code strukturiert wäre, kann das Risiko eingedämmt werden. Deshalb gehen wir all diese Mühe auf.

Komplexität entsteht aus Beziehungen, nicht aus Elementen

Ich stelle in Ihrer Analyse fest, dass Sie Mengen betrachten - Menge des Codes, Anzahl der Klassen usw. Obwohl diese Art von Interesse interessant ist, kommt der tatsächliche Einfluss auf die Beziehungen zwischen Elementen, die kombinatorisch explodieren. Wenn Sie beispielsweise 10 Funktionen haben und keine Vorstellung davon, welche davon abhängig ist, haben Sie 90 mögliche Beziehungen (Abhängigkeiten), um die Sie sich Sorgen machen müssen. Jede der zehn Funktionen kann von einer der neun anderen Funktionen und von 9 x 10 abhängig sein = 90. Möglicherweise haben Sie keine Ahnung, welche Funktionen welche Variablen ändern oder wie Daten weitergegeben werden. Codierer haben also eine Menge Dinge zu beachten, um bestimmte Probleme zu lösen. Wenn Sie dagegen 30 Klassen haben, die jedoch geschickt angeordnet sind, können sie bis zu 29 Beziehungen haben, z. wenn sie geschichtet oder in einem Stapel angeordnet sind.

Wie wirkt sich dies auf den Durchsatz Ihres Teams aus? Nun, es gibt weniger Abhängigkeiten, das Problem ist viel leichter zu lösen. Codierer müssen nicht jede Menge Dinge in ihrem Kopf jonglieren, wenn sie eine Änderung vornehmen. Das Minimieren von Abhängigkeiten kann daher einen erheblichen Beitrag dazu leisten, ein Problem kompetent zu begründen. Deshalb unterteilen wir die Dinge in Klassen oder Module und setzen die Variablen so eng wie möglich in den Umfang ein. > SOLID Prinzipien.

323
hinzugefügt
@ jpmc26 Was wäre ein Beispiel für ein nicht triviales OOP-Programm (z. B.> 10k loc), das eine minimale Anzahl von Klassen verwendet und einfach zu warten und zu lesen ist? Ich muss auch der Komplexität des Lesens des Codes widersprechen. Selbst ohne den Code in eine IDE zu laden, scheint es ziemlich einfach zu sein, von RestoreRunner.RunAsync bis RestoreCommand usw. zu folgen. Ich denke, das Problem ist, dass Sie vermisst haben, dass NuGets in diesen Tagen keine einfache Liste ist, sondern ein Baum mit PackageReference , der einen Haken in Ihr mentales Modell wirft.
hinzugefügt der Autor Kyle Hodgson, Quelle
@Holger Also, wann hat Mozilla Firefox seit einigen Jahren eingestellt, um seinen Browser vollständig neu zu schreiben? Sie haben es nicht getan. Sicher, Sie können Teile des Codes ersetzen und es gibt eine natürliche Entwicklung, aber eine vollständige Umschreibung ist Gift (die andere Firma, die MS zwischen IE6 und 8 gemacht hat. Funktionierte für sie nicht viel besser als Netscape).
hinzugefügt der Autor Kyle Hodgson, Quelle
@Holger Sie behaupten, dass heute "nur Browser, die entweder von Grund auf neu geschrieben wurden oder gar nicht so lange existieren". Dies ist offensichtlich falsch. Ich bezweifle, dass Sie ein beliebiges beliebtes Produkt finden, das von Grund auf neu geschrieben wurde und immer noch so erfolgreich ist wie zuvor (da das von Ihnen erwähnte Beispiel nicht zutrifft, bezweifle ich, dass Sie ein besseres wissen). Der einzige Browser-Anbieter, der seit Netscape etwas Ähnliches tat, war Microsoft nach dem IE6. Und sie wurden von einer 90% igen Mehrheit zu einem kleinen Spieler und das trotz der Bündelung des Browsers mit dem beliebtesten Betriebssystem der Welt ... ein großer Erfolg.
hinzugefügt der Autor Kyle Hodgson, Quelle
Das Umschreiben von Grund auf und das Second-System-Syndrom sind eine todsichere Methode, ein Produkt zu töten, weshalb niemand es in der Nähe tut. Sie verbessern den vorhandenen Code und implementieren neue Funktionen. Oder Sie entscheiden sich dafür, kleine Teile der Anwendung auf Basis der jeweiligen Anforderungen neu zu schreiben (Sicherheit oder Leistung in der Regel, sehr selten Wartbarkeit). Aber von Grund auf neu schreiben? Der Joel-Artikel gibt viele, viele Gründe, warum dies eine so schlechte Idee ist.
hinzugefügt der Autor Kyle Hodgson, Quelle
Ich würde jedoch bemerken, dass ein übermäßiges Angebot an Klassen und Indirektion weder für das Verständnis der NOR-Pflege hilfreich ist. Und auch keine komplizierten Kontrollflüsse (aka Callback-Hölle).
hinzugefügt der Autor Owen, Quelle
"Die Alternative besteht darin, die Wartung für die Wartung zu optimieren. Dadurch wird die Erstellung etwas schwieriger, aber Änderungen werden einfacher oder weniger riskant. Dies ist der Zweck von strukturiertem Code." Ich habe ein Problem mit der impliziten Vorstellung, dass mehr Klassen = mehr Wartbarkeit. Insbesondere die Streuung der Logik über viele Klassen hinweg macht es oft schwierig, die übergeordneten logischen Konzepte im Code zu finden (insbesondere ohne ein ganz bewusstes Auge dafür zu haben, dass die Konzepte sehr sichtbar sind), was die Wartbarkeit enorm beeinträchtigt.
hinzugefügt der Autor jmibanez, Quelle
Mein Go-to-Beispiel hierfür wurde kürzlich zu NuGets Wiederherstellungsbefehl . Die Wiederherstellung umfasst drei grundlegende Schritte: Lesen Sie die Liste der Pakete ein, laden Sie sie herunter und extrahieren Sie sie auf die Festplatte. Obwohl jeder dieser Schritte sicherlich komplex ist, ist es übermäßig schwierig zu ermitteln, wo diese im Code implementiert sind, teilweise aufgrund der relativ großen Anzahl von Objekten und teilweise aufgrund der Tatsache, dass das Aufdecken dieser Konzepte nicht so erscheint war eine Priorität bei der Benennung und Organisation.
hinzugefügt der Autor jmibanez, Quelle
@Voo Ich hatte Schwierigkeiten, herauszufinden, welches Objekt den Befehl gestartet hat. Das alles ist mit dem OO-Ansatz für das Parsing von Befehlszeilen verschleiert. Sobald Sie herausgefunden haben, dass es RestoreRunner ist, versuchen Sie zu verfolgen, wie seine "Anforderungen" erstellt werden. Dies führt Sie durch etwa 4 Methodenaufrufe, die in einem Aufruf eines Provider-Objekts münden, wenn ich lese es richtig. Einen Baum zu finden, ist nicht überraschend, aber das Auffinden von Bäumen erfordert viel zu viele Schichten. Ich bin nicht schlau Ich mag Code, der sorgfältig entwickelt wurde, um die Absicht dahinter aufzuzeigen, und der objektzentrierte Ansatz verstärkt die schlechten Abstraktionen.
hinzugefügt der Autor jmibanez, Quelle
@JohnWu NuGet versagt beim Modularisieren. Seine Seitenbibliotheken (wie NuGet.Frameworks ) sind vollständig undokumentiert (ich konnte nicht einmal die Quelle für ihren Build finden.), das Befehlszeilentool lässt viele Funktionen des VS-Plug-Ins vermissen, und wenn man den Code betrachtet, müssen so viele Objekte einfach erstellt werden Ein Teil funktioniert nur, wenn Sie die gesamte Codebasis sehr gut verstehen müssen, um einen Teil davon zu verwenden. Es ist bereits effektiv monolithisch, also kaufe ich dein Argument nicht.
hinzugefügt der Autor jmibanez, Quelle
@JohnWu Nur das ist die durchdringende Sicht auf Muster. DI wird religiös akzeptiert. Kein DI-Vertreter, von dem ich wüsste, sagt: "Hier sieht ein Problem aus, das DI gut für das Lösen ist", sagen sie, "Sie sollten OO-Code schreiben und das heißt, Sie sollten DI haben. Und oh, Sie sollten SOLID-Prinzipien folgen . " Praktisch niemand spricht darüber an, welche Probleme diese Ideen eigentlich lösen sollen. Sie werden nur als Regeln angeboten, die angeblich immer gelten.
hinzugefügt der Autor jmibanez, Quelle
@ R.Schmitz Wirklich gute Programmierer denken überhaupt nicht an Regeln. Sie denken in Bezug auf die Lösung von Problemen. Was noch wichtiger ist, gute Programmierer erkennen, wenn andere Programmierer nicht bereits in dieser Denkweise nachdenken, und treiben sie dazu, anstatt Regeln festzulegen.
hinzugefügt der Autor jmibanez, Quelle
@ R.Schmitz Ich sage wirklich gute Programmierer, die das Denken jedoch umkehren. Sie denken nicht, "Sie sollten Ihren Code für die Lesbarkeit optimieren." Sie denken: "Wir müssen das Problem lösen, Code verstehen zu können, um später oder von anderen Entwicklern Änderungen vornehmen zu können." Der erste führt zu einer Lösung, ohne das Problem zu erklären. Der zweite Teil weist auf das Problem hin und bleibt offen für andere Lösungen, und es hat ein Ziel, bei dem es viel klarer ist, ob Sie Erfolg haben oder nicht (obwohl es immer noch subjektiv ist).
hinzugefügt der Autor jmibanez, Quelle
Ich würde das volle 10 × 10 = 100 für das Kombinatorium wählen: Diese Funktionen könnten durchaus rekursiv sein und in besonders schlechtem Code nicht unbedingt notwendig sein.
hinzugefügt der Autor LessIsMore, Quelle
Gut geschrieben, aber fehlt vielleicht vielleicht, warum "einmal erstellt, aber viele, viele Male geändert" wichtig ist? (Wenn der gesamte Code in EntityTransformationServiceImpl enthalten ist, müssen Sie lernen, wie das Ganze funktioniert , bevor Sie das Problem beheben können - aber wenn z. B. das Format und ein Fehler vorliegen Die Klasse Formatter behandelt das, Sie müssen nur lernen, wie dieser Teil funktioniert . Außerdem ist das Lesen des eigenen Codes nach ~ 3 Monaten wie das Lesen eines fremden Codes.) Ich fühle mich am meisten von uns haben unbewusst daran gedacht, aber das könnte an der Erfahrung liegen. Nicht absolut sicher.
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Nein, denn wenn Sie neuen Code hinzufügen, ist der vorherige Code nicht so wichtig wie Ihre Schreibstandards. Wenn die Software es erschreckend teuer macht, Code hinzuzufügen, dann ist das nur chaotischer Code. Sie können ein perfekt modulares Projekt erstellen, fügen Sie jedoch schnell und einfach Code hinzu. Sie können auch ein ganzes Programm in einer Gottesschule haben, aber überlegen Sie, wie Sie Ihren Zusatz später pflegen können. In Bezug auf die Unternehmen, von denen Sie sprechen, habe ich nur von einem gehört und hieß es Netscape .
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Wenn ein Unternehmen ein neues Produkt erstellt, das keine Code-Basis umschreibt, ist es das Erstellen . Andernfalls argumentieren Sie, dass das heutige AutoCAD und 3DSMax usw. nur "Umschreiben" von 1968 ist. Ich sage auch nicht, dass es nicht passiert, nur dass es in diesen Fällen besser geworden wäre, wenn dies nicht der Fall wäre.
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Deine Interpretationen von dem, was ich gesagt habe, und von dem, was eine Umschreibung ist, sind falsch. Call of Duty ist keine Umschreibung von DOOM. Es ist ein völlig anderes Produkt von einem völlig anderen Entwickler. Sicher, Sie können sagen, dass jedes Stück Code nur eine Umschreibung des ersten Codes ist, das jemals geschrieben wurde, aber das Wort verliert nur jegliche praktische Bedeutung und Sie sollten wahrscheinlich hier eine Frage posten
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Look, Firefox wurde im Jahr 2004 veröffentlicht, also 14 Jahre; Android im Jahr 2007, das sind 11 Jahre. In der IT ist das nicht nur alt, das ist uralt . Ihrer Theorie nach sollte Firefox ein "veraltetes, gepatchtes" (zur gleichen Zeit), unbrauchbares Durcheinander bis 2006 oder Android im Jahr 2010 gewesen sein. Das ist nur die strikte Verweigerung der Effizienz von wartungsfähigem Code, weil sie jetzt besser sind In fast jedem Aspekt - Sicherheit, Benutzerfreundlichkeit, Funktionsumfang, nennen Sie es. Es scheint, als hätten Sie nur eine persönliche Agenda gegen wartbaren Code.
hinzugefügt der Autor R. Schmitz, Quelle
@ jpmc26 Das liegt daran, dass gute Programmierer wissen, dass alle "Regeln" pragmatisch angewendet werden müssen. Alle Regeln erhalten automatisch ein "außer wenn Sie einen wirklich guten Grund haben" am Ende . Wenn Sie mit Menschen arbeiten, die dogmatisch und nicht pragmatisch sind, wird sich das für jede -Regel als schlecht erweisen.
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Nochmals falsch. Ihre erste Aussage lautete: Die Software ist so konzipiert, dass die Erstellung fürchterlich teuer ist. Daher müssen wir sie so lange beibehalten und beibehalten, bis wir den Punkt erreicht haben, an dem dieses völlig veraltete, gepatchte Chaos sterben muss. "Der Artikel, den ich verlinkt habe, kann Ihnen einen tieferen Einblick geben, warum das Neuschreiben bei Interesse so schlecht ist. Ihre erste Aussage wurde von Firefox und Android als falsch befunden. Alles danach war nur eine Diskussion, für die die Kommentare nicht sind, also hören wir das hier jetzt auf.
hinzugefügt der Autor R. Schmitz, Quelle
@Holger Sie haben geschrieben, [A] könnte wichtig sein, weil [B] [C] verursacht. Das ist, worauf Ihr "könnte" angewendet wurde. Die Theorie, die Sie hatten, ist, dass [B] [C] verursacht. Zwei große Beispiele, bei denen dies nicht zutrifft, zeigen schnell, dass [B] [C] nicht verursacht. Wenn es sich um etwas anderes handelte, habe ich das nicht widerlegt und nur gezeigt, dass eines Ihrer Räumlichkeiten falsch war.
hinzugefügt der Autor R. Schmitz, Quelle
@ jpmc26 Ich füge "Regeln" in Anführungszeichen ein, weil sie Richtlinien sind . Eine Regel kann nicht mit "Sie sollten" beginnen. Wenn Sie nicht einmal grundlegende Richtlinien wie "" befolgen, sollten Sie Ihren Code für die Lesbarkeit optimieren "" oder "" "Außer wenn Sie einen wirklich guten Grund haben"), dann sind sie eher ein " echter Programmierer " als ein" wirklich guter Programmierer ".
hinzugefügt der Autor R. Schmitz, Quelle
@ jpmc26 Fair genug, aber wenn Sie die 5 Warum-Frage gefragt haben, nachdem Ihnen gesagt wurde "Sie sollten die Code-Konventionen Ihres Teams befolgen", ist dies nicht gut für Ihre Karriere. Manchmal ist es zu offensichtlich, die Erklärung immer hinzuzufügen.
hinzugefügt der Autor R. Schmitz, Quelle
@ jpmc26 "Ich nehme an, dass mehr Klassen = mehr Wartbarkeit sind." Hängt natürlich davon ab, was der Operand von "mehr" ist. In diesem Fall handelt es sich um "50K LOC-Code". Daher bin ich mir nicht sicher, ob ich im konkreten Kontext des OP-Beitrags einverstanden bin.
hinzugefügt der Autor John Wu, Quelle
Nuget ist wahrscheinlich kein hervorragendes Beispiel, da seine Modularität möglicherweise eher durch externe Anforderungen als durch Überdenken des Architekten bestimmt wird - schließlich handelt es sich dabei um ein erweiterbares Framework zum Verwalten von erweiterbaren Frameworks, das als PowerShell-Commandlet in einer Visual Studio-Erweiterung ausgeführt wird. Nun, wenn ich darüber nachdenke: Wenn all diese Dinge monlithisch geschrieben wären, könnte Nuget nicht einmal existieren.
hinzugefügt der Autor John Wu, Quelle
@ Holger In meinem Beitrag diskutiere ich zwei mögliche Optimierungsziele. Natürlich können Sie auch für andere Ziele optimieren, z. "Anzahl der Umschreibungen minimieren" (was der Optimierung der Wartbarkeit sehr ähnlich ist) oder "Vereinfachung der Umschreibung", die ähnlich ist wie die Optimierung der Produkterstellung (es gibt zusätzliche Anforderungen wie Abwärtskompatibilität und Feature-Parität). Ich gebe kein Ziel vor, ich möchte nur die Unterschiede hervorheben, um die Gründe für ein sorgfältiges Design zu erläutern.
hinzugefügt der Autor John Wu, Quelle
@Taw "Designmuster mit allen Mitteln und um jeden Preis religiös finden." Das klingt wie eine Entwurfsentscheidung (Ausgabe), nicht ein Entwurfsziel (Eingabe). Wenn Sie Ihre gewünschten Ausgaben von vorne in eine Optimierungseingabe laden, addiert der Prozess nicht viel (der Test der Endogenität wird nicht bestanden), dh Sie machen es falsch. Klingt so, als hätte Ihr Architekt nur ein "Pet NFR ", das immer schlecht ist.
hinzugefügt der Autor John Wu, Quelle
@JohnWu diese Erklärung ist der beste und verständlichste, den ich je gelesen habe.
hinzugefügt der Autor Les H, Quelle
Als ich zum ersten Mal das Codieren lernte, schrieb ich ein Programm alles innerhalb einer Klasse. Es funktionierte gut, aber an einem Punkt, an dem eine einfache Änderung 4 oder 5 Bugs mit sich brachte, für die ich einige Tage brauchte, um das Problem zu beheben. Ich fing an, nach Design zu forschen, und baute alles in ungefähr 10 Klassen auf, und meine Wartungsprobleme verschwanden. Ich habe viele Änderungen mit 0 Bugs vorgenommen, die nach diesem Refactor eingeführt wurden. Ich denke, dies ist eine Lektion, die man lernen muss, um zu verstehen, warum es sich lohnt.
hinzugefügt der Autor reggaeguitar, Quelle
@Voo das hängt von der Definition von "minimale Anzahl von Klassen" ab. Wir haben eine Anwendung, die aus Tausenden von Klassen besteht, aber ich weiß, wenn wir bestimmte häufig verwendete Frameworks und „Best Practices“ verwendeten, hatten wir das zwanzigfache dieser Anzahl…
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz das ist ein interessanter Punkt. "Einmal erstellt, aber viele, viele Male geändert" kann wichtig sein, weil die Software so entworfen wurde, dass die Erstellung fürchterlich teuer ist. Daher müssen wir sie so lange aufrechterhalten, bis wir den Punkt erreicht haben, an dem dies vollständig erreicht wird veraltetes, gepatchtes Chaos muss sterben. Nicht jeder folgt diesem Muster. Es gibt Unternehmen, bei denen die Veröffentlichung einer Software auch immer der Tag ist, an dem die Entwicklung der neuen Version beginnt, von Grund auf neu geschrieben wird und alle Lektionen einschließt, die aus der Entwicklung der vorherigen Version gelernt wurden, sowie neu hinzugekommene Technologien.
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz Wussten Sie, dass alle Browser dieser Zeit auf dem ursprünglichen Mosaik basierten, einschließlich z. den Internet Explorer, um einen zu nennen, der noch existiert? Was denken Sie, wie viele heutige Browser basieren noch darauf? Heute gibt es nur noch Browser, die entweder seitdem (mehr als einmal) von Grund auf neu geschrieben wurden oder gar nicht so lange existieren. In einer theoretischen Welt könnte dieser erste Browser in einer modularen, erweiterbaren und zukunftssicheren Art und Weise geschrieben worden sein und für alle Änderungen bereit sein, die die Zukunft bringen wird. In Wirklichkeit nicht. Anforderungen und Technologien ändern sich zu sehr.
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz Sie sagen also, es wäre besser, wenn "Call of Duty: Modern Warfare 3" auf Dooms Quellcode basiert und dass dies ein Zeichen für Dooms schlechtes Softwaredesign ist nicht Oder bestätigen Sie tatsächlich meinen Standpunkt, dass alte Software durch neue ersetzt wird, da die Aktualisierung der alten Software unendlich oft eine Illusion ist?
hinzugefügt der Autor Holger, Quelle
Ich sehe nicht, wo ich behauptet habe, dass alle Softwareentwickler das tun. Vielleicht haben Sie recht, und Firefox wurde nie von Grund auf neu gestaltet, als es als völlig neu konzipierter Ersatz für Netscape begann. Vielleicht ist das ein Zeichen dafür, wie gut Firefox entwickelt wurde. Oder Sie starten gerade einen Flamewar, da die Qualität von Firefox wirklich umstritten ist. Öffnen Sie nicht die Dose Würmer.
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz Es scheint, dass Sie den Punkt völlig verfehlen. Es ist egal, ob es sich bei neuer Software um ein "Umschreiben" eines alten oder eines völlig neuen Produkts handelt. Der Punkt ist, es ist neue Software, für die es keine Rolle spielt, wie einfach die Wartung der alten ist. Verstehst du es jetzt? Alte Software wird sterben. Alte Software wird durch neue ersetzt. Das ist eine unvermeidliche Tatsache. Sie können nur beeinflussen, ob das Neue von Ihnen oder das Ihrer Mitbewerber ist. Sie können Ihre Software jedoch auch für die Wartung optimieren, die Entwicklung neuer Software teuer machen und vermeiden, für immer neue zu schreiben.
hinzugefügt der Autor Holger, Quelle
@Voo genau, Microsoft war der einzige, der seinen Browser von Grund auf neu geschrieben hat. Nun benennen Sie einen beliebigen -Browser außer dem zu diesem Zeitpunkt bereits bestehenden Microsoft-Browser (Netscape 4 oder früher), der heute noch existiert (ohne größere Umschreibung, dh er basiert noch immer auf Mosaic-Code). Tatsächlich hat Netscape auch eine Umschreibung vorgenommen, diese aber an die Mozilla-Stiftung ausgelagert, was zur Entwicklung von Firefox geführt hat. Das Umschreiben „tötete“ das Produkt, weil es das neue Produkt gebar. Denken Sie, dass ein Netscape-Browser, der auf dem alten Code basiert, noch heute existieren könnte? Mozilla widersprach.
hinzugefügt der Autor Holger, Quelle
@JohnWu deine Art und Weise, Optimierungen als Funktion verschiedener Ziele zu beschreiben, ist sehr gut, ich widerspreche dem nicht. Das ist eine wirklich gute Antwort.
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz, außer dass der Hauptsponsor von Firefox einmal beschlossen hat, seinen eigenen Browser namens Chrome zu schreiben, der nicht auf Firefox basiert, sondern Sie haben Recht. Firefox ist uralt. Was möchten Sie jedoch beweisen? Meine ursprüngliche Aussage war, dass heute kein Browser auf Mosaic basiert, da alle vorhandenen Browser seitdem vollständig neu geschrieben wurden oder viel jünger sind. In Anbetracht dessen, dass Mosaic aus dem Jahr 1993 stammt, ist Firexfox viel jünger als das. Sie haben mich also nicht als falsch erwiesen. Abgesehen davon bin ich nicht gegen wartbaren Code, habe das nie gesagt. Ich bin eher gegen Code, der nur weiß, dass wächst .
hinzugefügt der Autor Holger, Quelle
@ R.Schmitz rippst du diese Phrase aus dem Kontext. Der Satz wurde lauten: "" einmal erstellt, aber viele, viele Male geändert ". könnte wichtig sein, da die Software so entworfen wurde, dass das Erstellen von furchtbarem Aufwand… " ist. Es ist eine Spekulation über ein Muster, das möglicherweise auf eine bestimmte Menge von Softwareprojekten angewendet wird. Sie haben den Punkt bereits verpasst, als Sie eine Diskussion über auserlesene Software eröffneten, zwei Beispiele IIRC, die seit langem gepflegt werden und alle Milliarden von Software ignorieren, die gestorben sind. Diese spekulative Aussage ist nicht nur an zwei Beispielen "falsch".
hinzugefügt der Autor Holger, Quelle
Tolle Antwort, aber ..: Die Alternative besteht darin, für die Wartung zu optimieren. bedeutet, dass dies die einzige ist, über die sich OP beschwert. Es gibt auch eine Optimierung, um Designmuster mit allen Mitteln und um jeden Preis religiös zu finden . Das Schlüsselwort ist smart und durch das Erstellen vieler Klassen ist es nicht gegeben. DI ist ein großartiges/schreckliches Beispiel, bei dem Sie, wie ein weiser Mann schrieb, ein 50c-Konzept für 100-Dollar-Schlagworte erhalten.
hinzugefügt der Autor pong, Quelle
Eine gute Antwort, aber mit eklatanter Auslassung: Es ist sehr wahrscheinlich, dass "600 Zeilen unordentlichen Code" nicht ordnungsgemäß getestet werden können, und dies allein ist ein Dealbreaker für den im OP vertretenen Ansatz.
hinzugefügt der Autor Nath, Quelle

Zunächst einmal liegen Lesbarkeit und Haltbarkeit oft im Auge des Betrachters.

Was für Sie lesbar ist, kann für Ihren Nachbarn nicht sein.

Die Wartbarkeit läuft oft auf Entdeckbarkeit an (wie leicht wird ein Verhalten oder ein Konzept in der Codebase entdeckt) und Entdeckbarkeit ist eine weitere subjektive Sache.

DDD

DDD hilft Entwicklerteams unter anderem, eine bestimmte (aber dennoch subjektive) Methode zur Organisation Ihrer Codekonzepte und Verhaltensweisen vorzuschlagen. Diese Konvention erleichtert das Erkennen von Dingen und somit die Wartung der Anwendung.

  • Domänenkonzepte werden als Entitäten und Aggregate
  • codiert
  • Domainverhalten liegt in Entitäten oder Domain-Services
  • Die Konsistenz wird durch die Aggregate Roots
  • sichergestellt
  • Persistenzbedenken werden von Repositories
  • behandelt

Diese Anordnung ist objektiv nicht einfacher zu warten. Es ist jedoch messbar einfacher zu warten, wenn jeder versteht, dass er in einem DDD-Kontext arbeitet.

Klassen

Klassen help with maintainability, readability, discoverability, etc... because they are a well known convention.

In Object Oriented settings, Klassen are typically used to group closely related behaviour and to encapsulate state that needs to be controlled carefully.

Ich weiß, dass das sehr abstrakt klingt, aber Sie können so darüber nachdenken:

With Klassen, you don't necessarily need to know how the code in them works. You just need to know what the class is responsible for.

Klassen allow you to reason about your application in terms of interactions between well defined components.

Dies reduziert die kognitive Belastung, wenn Sie darüber nachdenken, wie Ihre Anwendung funktioniert. Anstatt sich daran zu erinnern, was 600 Zeilen Code leistet, können Sie darüber nachdenken, wie 30 Komponenten zusammenwirken.

In Anbetracht dieser 30 Komponenten, die sich wahrscheinlich auf 3 Schichten Ihrer Anwendung erstrecken, müssen Sie wahrscheinlich immer nur etwa zehn Komponenten gleichzeitig berücksichtigen.

Das scheint ziemlich überschaubar zu sein.

Zusammenfassung

Im Wesentlichen sehen Sie, dass die Senior-Entwickler Folgendes tun:

They are breaking down the application into easy to reason about Klassen.

Sie organisieren diese dann in einfache Gründe für -Layer.

They are doing this because they know that, as the application grows, it becomes harder and harder to reason about it as a whole. Breaking it down into Layers and Klassen means that they never have to reason about the entire application. They only ever need to reason about a small subset of it.

64
hinzugefügt
Außerdem sind kleinere Klassen leichter zu ersetzen/zu refactorieren.
hinzugefügt der Autor Pieter, Quelle
"Mit Klassen müssen Sie nicht unbedingt wissen, wie der Code in ihnen funktioniert. Sie müssen nur wissen, wofür die Klasse verantwortlich ist." Klassen sind definitiv nicht der einzige Weg, um dies zu erreichen, obwohl sie unter Umständen ein nützlicher Weg sein können. Noch wichtiger ist jedoch, dass nicht Klassen verwendet werden, die dies erreichen. Es ist eine gute Designauswahl von einem Entwickler, der dies tut. Der Unterricht ist keine magische Sauce, die Ihnen dies in jeder Hinsicht gibt.
hinzugefügt der Autor jmibanez, Quelle
Nach Ansicht des OP, der "viel damit zu kämpfen hat, sein Denken und Argumentieren zu verstehen", scheint es, dass die Gründe für die Erstellung von Code, über den leicht zu denken ist, nicht so leicht zu begründen sind.
hinzugefügt der Autor Erb, Quelle
Ja, Overngineering ist schlecht. So tötet Welpen. Niemand hier spricht sich dafür aus. logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/ & hellip;
hinzugefügt der Autor Warpspace, Quelle
Auch "Eleganz" im Software-Engineering-Kontext ist oft ein Wieselwort. de.wikipedia.org/wiki/Weasel_word
hinzugefügt der Autor Warpspace, Quelle
Das Gleiche kann für jeden Ansatz zur Organisation von Code gesagt werden. Alles hängt davon ab, dass das Wartungsteam versteht, warum der Code so organisiert ist, wie er ist. Das ist der springende Punkt, wenn man etablierte und verstandene Konventionen verwendet.
hinzugefügt der Autor Warpspace, Quelle
@ jpmc26 Ich stimme zu, Klassen sind keine Zauberei. Sie bieten jedoch häufig Unterstützung auf Sprachenebene für Dinge wie Kapselung und öffentliche Aufträge.
hinzugefügt der Autor Warpspace, Quelle
@ icc97 es klingt so, als würden Sie sagen, dass Erfahrung, Kontext und das Wissen um Konventionen und Muster einen großen Unterschied ausmachen. Und dass es einem Junior-Entwickler möglicherweise an diesen Dingen fehlt, was es für ihn schwierig macht, Code zu schreiben, der mit diesen Dingen geschrieben wurde.
hinzugefügt der Autor Warpspace, Quelle
Overengineering gibt keinen wartbaren oder verständlicheren Code - ganz im Gegenteil, trotz Ihrer Behauptung. Wer benötigt einen AddressServiceRepositoryProxyInjectorResolver , wenn Sie das Problem eleganter lösen können? Entwurfsmuster für Designmuster führen nur zu unnötiger Komplexität und Ausführlichkeit.
hinzugefügt der Autor Ian Yates, Quelle
Gute Antwort! Ich bin überrascht über die Kommentare, die nicht mit Ihnen übereinstimmen
hinzugefügt der Autor reggaeguitar, Quelle
Wenn sie zuerst in Klassen einbrechen und dann diese Klassen in Schichten zusammenfassen, ist es kein Wunder, dass die Dinge unordentlich werden. Sie möchten es andersherum machen (Sie möchten zunächst Klassen einführen).
hinzugefügt der Autor Clearer, Quelle
und dann braucht man nur einen Schraubenschlüssel, um das gesamte Muster zu durchbrechen
hinzugefügt der Autor user2890248, Quelle

Bitte erklären Sie mir, warum brauchen wir diesen DDD-Stil, viele Patterns?

Zunächst ein Hinweis: Der wichtige Teil von DDD sind nicht die -Muster , sondern die Ausrichtung des Entwicklungsaufwands an das Unternehmen. Greg Young bemerkte, dass die Kapitel in dem blauen Buch in der falschen Reihenfolge stehen .

Aber zu Ihrer spezifischen Frage: In der Regel gibt es viel mehr Klassen, als Sie erwarten würden, (a) weil versucht wird, das Domänenverhalten von den Sanitärinstallationen zu unterscheiden, und (b) weil zusätzliche Anstrengungen unternommen werden, um diese Konzepte sicherzustellen im Domänenmodell werden explizit ausgedrückt.

Wenn Sie zwei unterschiedliche Konzepte in der Domäne haben, sollten sie sich eindeutig im Modell unterscheiden, auch wenn sie in der Speicherdarstellung dasselbe haben.

Tatsächlich erstellen Sie eine domänenspezifische Sprache, die Ihr Modell in der Geschäftssprache beschreibt, so dass ein Domänenexperte in der Lage sein sollte, es zu betrachten und Fehler zu erkennen.

Additionally, you see a bit more attention paid to separation of concerns; and the notion of insulating consumers of some capability from the implementation details. See D. L. Parnas. The clear boundaries empower you to change or extend the implementation without the effects rippling throughout you entire solution.

Die Motivation hier: Für eine Anwendung, die Teil der Kernkompetenz eines Unternehmens ist (dh einen Ort, an dem ein Wettbewerbsvorteil entsteht), möchten Sie ein Domain-Verhalten einfach und kostengünstig durch eine bessere Variation ersetzen können. In der Tat haben Sie Teile des Programms, die Sie schnell entwickeln möchten (wie sich der Status im Laufe der Zeit entwickelt), und andere Teile, die Sie langsam ändern möchten (wie der Status gespeichert wird). Die zusätzlichen Abstraktionsebenen verhindern, dass sie versehentlich miteinander gekoppelt werden.

In Fairness: Ein Teil davon ist auch objektorientierter Hirnschaden. Die ursprünglich von Evans beschriebenen Muster basieren auf Java-Projekten, an denen er vor über 15 Jahren beteiligt war. Zustand und Verhalten sind in diesem Stil eng miteinander verknüpft, was zu Komplikationen führt, die Sie möglicherweise vermeiden möchten. Siehe Wahrnehmung und Aktion von Stuart Halloway oder Inlining-Code von John Carmack.

Egal in welcher Sprache Sie arbeiten, die Programmierung in einem funktionalen Stil bietet Vorteile. Sie sollten es tun, wann immer es bequem ist, und Sie sollten über die Entscheidung nachdenken, wenn es nicht bequem ist. Carmack, 2012

29
hinzugefügt
Ich denke, das ist die beste Antwort hier. Obwohl ich keinesfalls über DDD verkauft werde, erklärt diese Antwort zumindest, was es wirklich ist und eine tatsächliche Motivation dafür, anstatt sich auf gewöhnliche Plattitüden zu richten, die nichts bedeuten.
hinzugefügt der Autor jmibanez, Quelle
John Carmack ist ein hervorragendes Beispiel für IMO, da er für das Schreiben von Code bekannt ist, der sowohl sauber als auch leicht verständlich ist und gleichzeitig gute Ergebnisse liefert. Dies ist besonders sichtbar, wenn Sie seinen Code mit fortschreitenden Technologien nachverfolgen. Mit besseren CPUs und Speicher können Sie eine Reihe von Dingen sehen, die von "Dies muss sehr knapp" zu "Dies muss wirklich klar/isoliert/..." ". Einer der pragmatischsten Programmierer, die ich kenne :)
hinzugefügt der Autor Luaan, Quelle
Ich würde meine eigene Antwort hinzufügen, bis ich das hier gelesen habe. Ich möchte den ersten Absatz betonen, dass das Ziel darin besteht, Geschäftskonzepte in Software zu modellieren, um die Software an die Geschäftsanforderungen anzupassen. Aus Gründen der Fairness sollte der Analytiker, der das Projekt betreibt, auch angeben, wie viel Zeit der Fahrer bis zur Auslieferung hat, und die Code-/Testqualität oder -vollständigkeit sollte entsprechend angepasst werden.
hinzugefügt der Autor Sentinel, Quelle

In den anderen Antworten gibt es viele gute Punkte, aber ich denke, dass sie einen wichtigen konzeptionellen Fehler, den Sie machen, übersehen oder nicht unterstreichen:

Sie vergleichen den Aufwand, um das gesamte Programm zu verstehen.

Dies ist bei den meisten Programmen keine realistische Aufgabe. Selbst einfache Programme bestehen aus so viel Code, dass es unmöglich ist, den gesamten Inhalt zu einem bestimmten Zeitpunkt im Kopf zu verwalten. Ihre einzige Chance besteht darin, den Teil eines Programms zu finden, der für die anstehende Aufgabe relevant ist (Beheben eines Fehlers, Implementieren einer neuen Funktion), und damit arbeiten.

Wenn Ihr Programm aus umfangreichen Funktionen/Methoden/Klassen besteht, ist dies fast unmöglich. Sie müssen Hunderte von Codezeilen verstehen, um zu entscheiden, ob dieser Codeabschnitt für Ihr Problem relevant ist. Mit den Schätzungen, die Sie abgegeben haben, können Sie leicht eine Woche damit verbringen, den Code zu finden, an dem Sie arbeiten müssen.

Vergleichen Sie das mit einer Codebasis mit kleinen Funktionen/Methoden/Klassen, die benannt und in Paketen/Namespaces organisiert sind. Dadurch wird deutlich, wo ein bestimmter Teil der Logik zu finden ist. Wenn dies in vielen Fällen richtig ist, können Sie direkt an die richtige Stelle springen, um Ihr Problem zu lösen, oder zumindest an eine Stelle, von der aus Sie Ihren Debugger mit ein paar Sprüngen an die richtige Stelle bringen.

Ich habe in beiden Arten von Systemen gearbeitet. Bei vergleichbaren Aufgaben und vergleichbarer Systemgröße kann der Unterschied leicht zwei Größenordnungen betragen.

Die Auswirkung auf andere Aktivitäten:

  • Testen wird mit kleineren Einheiten viel einfacher
  • weniger Zusammenführungskonflikte, da die Wahrscheinlichkeit geringer ist, dass zwei Entwickler an demselben Code arbeiten.
  • weniger Duplizierung, da es einfacher ist, Teile wiederzuverwenden (und die Teile überhaupt zu finden).
26
hinzugefügt

Weil das Testen von Code schwieriger ist als das Schreiben von Code

Viele Antworten haben aus Sicht des Entwicklers gute Argumente geliefert - dass die Wartung reduziert werden kann, was den Code anstrengender macht, wenn er überhaupt erst geschrieben wird.

However, there is another aspect to consider - testing can only be fine-grained as your original code.

Wenn Sie alles in einen Monolithen schreiben, ist der einzige effektive Test, den Sie schreiben können, "bei diesen Eingaben, ist die Ausgabe korrekt?". Dies bedeutet, dass alle gefundenen Fehler "irgendwo in diesem riesigen Code-Haufen" enthalten sind.

Natürlich können Sie einen Entwickler dann mit einem Debugger sitzen lassen, um herauszufinden, wo das Problem begann und an einer Korrektur arbeiten. Dies erfordert viele Ressourcen und nutzt die Zeit eines Entwicklers schlecht. Stellen Sie sich vor, der kleine Fehler, den Sie haben, führt dazu, dass ein Entwickler das gesamte Programm erneut debuggen muss.

Die Lösung: Viele kleinere Tests, die jeweils einen bestimmten, potenziellen Fehler aufzeigen.

Diese kleinen Tests (z. B. Unit-Tests) haben den Vorteil, dass sie einen bestimmten Bereich der Codebase überprüfen und dabei helfen, Fehler in einem begrenzten Umfang zu finden. Dies beschleunigt nicht nur das Debuggen, wenn ein Test fehlschlägt, sondern auch, wenn alle kleinen Tests fehlschlagen. Sie können den Fehler in größeren Tests leichter finden (dh, wenn er sich nicht in einer bestimmten getesteten Funktion befindet, muss er in der Interaktion liegen.) zwischen ihnen).

Es sollte klar sein, dass bei kleineren Tests die Codebase in kleinere testbare Chunks aufgeteilt werden muss. Die Art und Weise, wie dies auf einer großen kommerziellen Codebase geschieht, führt häufig zu Code, der so aussieht, als würde er damit arbeiten.

Nur als Randbemerkung: Dies bedeutet nicht, dass die Leute die Dinge nicht "zu weit" nehmen. Es gibt jedoch einen legitimen Grund, Codebasis in kleinere/weniger zusammenhängende Teile zu unterteilen - sofern sinnvoll.

19
hinzugefügt
Während Ihre Antwort nur das Testen und die Testbarkeit anspricht, ist dies das wichtigste Problem, das einige der anderen Antworten vollständig ignoriert haben, also +1.
hinzugefügt der Autor Nath, Quelle

Bitte erklären Sie mir, warum brauchen wir diesen DDD-Stil, viele Patterns?

Viele (die meisten ...) von uns brauchen sie wirklich nicht. Theoretiker und sehr fortgeschrittene, erfahrene Programmierer schreiben Bücher über Theorien und Methodiken als Ergebnis vieler Recherchen und ihrer tiefen Erfahrung - das bedeutet nicht, dass alles, was sie schreiben, für jeden Programmierer in ihrer täglichen Praxis anwendbar ist.

Als junger Entwickler ist es gut, Bücher wie das von Ihnen erwähnte zu lesen, um Ihre Perspektive zu erweitern und Sie auf bestimmte Probleme aufmerksam zu machen. Es erspart Ihnen auch, peinlich zu werden, wenn Ihre älteren Kollegen Terminologie verwenden, mit der Sie nicht vertraut sind. Wenn Sie etwas sehr Schwieriges finden und nicht sinnvoll erscheinen oder nützlich erscheinen, töten Sie sich nicht darüber - legen Sie es einfach in Ihrem Kopf ab, dass es ein solches Konzept oder einen solchen Ansatz gibt.

In Ihrer täglichen Entwicklung besteht die Aufgabe darin, praktikable, wartbare Lösungen zu finden, es sei denn, Sie sind Wissenschaftler. Wenn die Ideen, die Sie in einem Buch finden, Ihnen nicht dabei helfen, dieses Ziel zu erreichen, machen Sie sich jetzt keine Sorgen, solange Ihre Arbeit als zufriedenstellend gilt.

Es kann eine Zeit kommen, in der Sie feststellen, dass Sie etwas von dem verwenden können, was Sie gelesen haben, aber auf den ersten Blick nicht ganz "verstanden" haben oder vielleicht auch nicht.

17
hinzugefügt
Wollen Sie damit sagen, dass sich in Ihren 20 Jahren Erfahrung niemals die gleiche Lösung als Teil eines Problems präsentiert hat? Sie haben immer eine völlig neue Lösung erstellt, wenn Sie zwei Klassen miteinander interagieren lassen? Jeder verwendet Muster immer wieder, die Bücher sind nur da, also benennen wir sie genauso, wenn wir über sie sprechen.
hinzugefügt der Autor Rob Hunter, Quelle
Auf einer reinen Ebene ist dies richtig, es klingt wie DDD und andere Patterns sind nur Theorie. Sie sind nicht Sie sind wichtige Werkzeuge, um lesbaren und wartbaren Code zu erhalten.
hinzugefügt der Autor Moogie, Quelle
@vikingsteve OP ist kein Programmierguru, der die generelle Überbeanspruchung von Entwurfsmustern kommentiert. OP ist ein Lehrling und meint , dass sie in seinem Laden überlastet sind . Ich weiß, dass Anfänger-ich dasselbe über den Code gedacht hätte, den ich heutzutage schreibe, aber Anfänger-Ich hatte eine Menge persönlicher Projekte zum Scheitern verurteilt, weil sie zu kompliziert wurden.
hinzugefügt der Autor R. Schmitz, Quelle
@Vector Ich bin etwas verblüfft, wie gut diese Änderungen waren. Das ging von "scheint mein Meinung" zu "100% ige Zustimmung" für mich, definitiv +1!
hinzugefügt der Autor R. Schmitz, Quelle
@Luaan Wenn du dich schon um gut gestaltete, organisierte, strukturierte OOP gekümmert hast, würde ich das kaum Anfänger-dich nennen, aber die Überbeanspruchung ist schlecht. Die Frage ist jedoch mehr, wie OP nicht wirklich versteht, welche Probleme diese Dinge lösen. Wenn Sie den Grund nicht kennen, scheint es keinen Grund zu geben - aber eigentlich wissen Sie es noch nicht.
hinzugefügt der Autor R. Schmitz, Quelle
@JensSchauder - Ich habe die Antwort im Lichte Ihres Kommentars bearbeitet. Ich stimme zu, dass es einfach falsch ist, es "Theorie" zu nennen. "Methodik" ist viel passender.
hinzugefügt der Autor Vector, Quelle
@ R.Schmitz - Ich habe die Kommentare gelesen und festgestellt, dass meine Sprache nicht wirklich genau ist und sich meine Position etwas extrem anhört.
hinzugefügt der Autor Vector, Quelle
@PeteKirkham Das Dilemma der OPs ist die Überbeanspruchung der Entwurfsmuster. Benötigen Sie wirklich einen AccountServiceFacadeInjectResolver (reales Beispiel, das ich gerade in einem System gefunden habe) - Antwort ist höchstwahrscheinlich nein.
hinzugefügt der Autor Ian Yates, Quelle
@ R.Schmitz Das heißt, Anfänger hatten viele persönliche Projekte, die scheiterten, weil sie sich zu sehr bemühten, die Dinge gut gestaltet, organisiert, strukturiert, OOP zu machen ... All dies sind Werkzeuge. Sie müssen verstanden und richtig verwendet werden, und Sie können dem Hammer kaum die Schuld dafür geben, dass er schlecht geschraubt ist. Überraschenderweise scheint es viel Einsicht und Erfahrung zu benötigen, um diese einfache Sache zu verstehen :)
hinzugefügt der Autor Luaan, Quelle
Das Seltsame an meiner Erfahrung ist, dass ich AccountServiceFacadeInjectResolver-Dinge häufiger im Code finde, die DDD NICHT verwenden. Spring-basierte Anwendungen scheinen fast ausschließlich Klassen zu sein, die mehr mit dem Ausfüllen des Frameworks als mit der Problemdomäne zu tun haben.
hinzugefügt der Autor Rob Crawford, Quelle

Da Ihre Frage viel Grund und viele Annahmen beinhaltet, werde ich das Thema Ihrer Frage herausgreifen:

Warum brauchen wir so viele Klassen in Designmustern

?

Wir nicht Es gibt keine allgemein anerkannte Regel, nach der es viele Klassen in Entwurfsmustern geben muss.

Es gibt zwei wichtige Leitfäden, mit denen Sie entscheiden können, wo Sie Code einfügen und wie Sie Ihre Aufgaben in verschiedene Codeeinheiten unterteilen können:

  • Kohäsion: Jede Codeeinheit (sei es ein Paket, eine Datei, eine Klasse oder eine Methode) sollte zusammengehören . Eine bestimmte Methode sollte eine eine -Aufgabe haben und dies gut tun. Jede Klasse sollte für ein größeres Thema verantwortlich sein (was auch immer das ist). Wir wollen eine hohe Kohäsion.
  • Kopplung: Zwei beliebige Code-Einheiten sollten so wenig wie möglich voneinander abhängig sein - insbesondere sollten keine zirkularen Abhängigkeiten bestehen. Wir wollen eine geringe Kopplung.

Warum sollten diese beiden wichtig sein?

  • Kohäsion: Eine Methode, die viele Dinge erledigt (z. B. ein altmodisches CGI-Skript, das GUI, Logik, Datenbankzugriff usw. in einem langen Code-Code durchführt) wird unhandlich. Zum Zeitpunkt des Schreibens ist es verlockend, Ihren Gedankengang in eine lange Methode zu stecken. Das funktioniert, es ist einfach zu präsentieren und so, und Sie können damit fertig werden. Probleme entstehen später: Nach einigen Monaten können Sie vergessen, was Sie getan haben. Eine Codezeile am oberen Rand kann einige Bildschirme von einer Zeile am unteren Rand entfernt sein. Es ist leicht, alle Details zu vergessen. Jede Änderung an einer beliebigen Methode in der Methode kann jede Menge Verhalten der komplexen Sache beeinträchtigen. Es wird ziemlich schwerfällig sein, Teile der Methode umzugestalten oder wiederzuverwenden. Und so weiter.
  • Kopplung: Jedes Mal, wenn Sie eine Codeeinheit ändern, brechen Sie möglicherweise alle anderen Einheiten, die davon abhängig sind. In strengen Sprachen wie Java erhalten Sie möglicherweise Hinweise zur Kompilierzeit (d. H. Zu Parametern, deklarierten Ausnahmen usw.). Viele Änderungen lösen jedoch keine solchen aus (d. H. Verhaltensänderungen), und andere, dynamischere Sprachen haben keine derartigen Möglichkeiten. Je höher die Kopplung, desto schwieriger wird es, etwas zu ändern, und Sie können zum Stillstand kommen, wo ein komplettes Neuschreiben erforderlich ist, um ein bestimmtes Ziel zu erreichen.

Diese beiden Aspekte sind die "Treiber" für die Wahl einer beliebigen Programmiersprache und für jedes Paradigma (nicht nur für OO). Nicht jeder ist sich dessen explizit bewusst, und es braucht Zeit, oft Jahre, um ein tief verwurzeltes, automatisches Gefühl dafür zu bekommen, wie diese Software beeinflussen.

Offensichtlich sagen diese beiden Konzepte nichts darüber, was eigentlich ist. Manche Menschen irren zu viel, andere zu wenig. Einige Sprachen (Java, die Sie hier betrachten) tendieren dazu, viele Klassen wegen der extrem statischen und pedantischen Natur der Sprache selbst zu bevorzugen (dies ist keine Werteanweisung, aber es ist was es ist). Dies macht sich besonders bemerkbar, wenn Sie es mit dynamischen und ausdrucksstarken Sprachen vergleichen, zum Beispiel Ruby.

Ein anderer Aspekt ist, dass einige Leute den agilen Ansatz akzeptieren, nur Code zu schreiben, der gerade jetzt notwendig ist, und später, wenn nötig, stark umgestaltet werden. In diesem Entwicklungsstil würden Sie keine -Schnittstelle erstellen, wenn Sie nur eine implementierende Klasse haben. Sie würden einfach die konkrete Klasse implementieren. Wenn Sie später eine zweite Klasse benötigen, würden Sie umgestalten.

Manche Leute arbeiten einfach nicht so. Sie erstellen Schnittstellen (oder allgemeiner abstrakte Basisklassen) für alles, was jemals allgemeiner verwendet werden könnte. Dies führt schnell zu einer Klassenexplosion.

Wiederum gibt es Argumente für und gegen, und es ist egal, was ich oder Sie bevorzugen. In Ihrem Leben als Softwareentwickler werden Sie allen Extremen begegnen, von langen Spaghetti-Methoden über aufgeklärte, ausreichend große Klassendesigns bis hin zu unglaublich gesprengten Klassensystemen, die viel überentwickelt sind. Je erfahrener Sie werden, desto mehr entwickeln Sie sich in "architektonische" Rollen und können dies in die von Ihnen gewünschte Richtung beeinflussen. Sie werden eine goldene Mitte für sich herausfinden, und Sie werden immer noch feststellen, dass viele Menschen Ihnen widersprechen werden, was auch immer Sie tun.

Daher ist Offenheit das Wichtigste hier, und das wäre mein primärer Rat an Sie, da Sie den Eindruck haben, dass Sie an dem Problem leiden, wenn Sie den Rest Ihrer Frage beurteilen ...

8
hinzugefügt

Erfahrene Programmierer haben gelernt:

  • Weil diese kleinen Programme und Klassen wachsen, besonders erfolgreich. Diese einfachen Muster, die auf einer einfachen Ebene funktionierten, skalieren nicht.
  • Es mag zwar lästig erscheinen, für jedes Hinzufügen/Ändern mehrere Artefakte hinzufügen/ändern zu müssen, aber Sie wissen, was Sie hinzufügen müssen, und das ist einfach. 3 Minuten Tippen sind 3 Stunden kluge Kodierung.
  • Viele kleine Klassen sind nicht "chaotisch", nur weil Sie nicht verstehen, warum der Aufwand eigentlich eine gute Idee ist.
  • Ohne das hinzugefügte Domänenwissen ist der Code "offensichtlich für mich" für meine Teamkollegen oft mysteriös ... und die Zukunft für mich.
  • Stammeswissen kann es unglaublich schwierig machen, Teammitglieder schnell und unkompliziert hinzuzufügen, um schnell produktiv zu sein.
  • Das Benennen ist eines der zwei schwierigen Probleme in der Datenverarbeitung. Es ist immer noch wahr und viele Klassen und Methoden sind oft eine intensive Übung in der Benennung, die für viele von großem Nutzen ist.
7
hinzugefügt
@vikingsteve Sie beziehen sich immer wieder auf ein einzelnes Beispiel einer fehlerhaften Implementierung, in der Hoffnung, dass strukturierter Code im Allgemeinen eine schlechte Idee ist. Das geht einfach nicht nach.
hinzugefügt der Autor Warpspace, Quelle
@Clearer Ich bin mir ziemlich sicher, dass sich alle hier einig sind, dass die hypothetische Fehlanwendung von strukturiertem Code eine schlechte Sache ist. Das OP sagt, dass sie Junior sind. Deshalb gehen die Leute davon aus, dass er/sie mit den Vorteilen von strukturiertem Code nicht vertraut ist und diese wiederholt.
hinzugefügt der Autor Warpspace, Quelle
Aber ist der Aufwand notwendig? In vielen Fällen, die ich sehe, werden Designmuster überbeansprucht. Die Folge von Überkomplexität ist die Schwierigkeit, Code zu verstehen, zu warten, zu testen und zu debuggen. Wenn Sie 12 Klassen und 4 Maven-Module für eine einfache Service-Klasse haben (ein echtes Beispiel, das ich gerade gesehen habe), wird dies schnell weniger handhabbar als Sie vielleicht denken.
hinzugefügt der Autor Ian Yates, Quelle
@MetaFight OP spricht nicht über Strukturcode. Er spricht von zu vielen Abstraktionen. Wenn Sie zu viele Abstraktionen haben, bekomme ich schnell sehr unstrukturierten Code und viele nahezu identische Teile.
hinzugefügt der Autor Clearer, Quelle

Wenn Sie mehr Klassen und Funktionen nach Bedarf erstellen, ist dies ein guter Ansatz, um Probleme auf eine bestimmte Art und Weise zu lösen, die in Zukunft zur Lösung von Problemen beitragen.

Mehrere Klassen helfen dabei, ihre grundlegende Arbeit zu identifizieren, und jede Klasse kann jederzeit aufgerufen werden.

Wenn Sie jedoch viele Klassen und Funktionen aus ihrem Namen erhalten, können Sie sie leicht aufrufen und verwalten. Dies wird als sauberer Code bezeichnet.

4
hinzugefügt
Sorry, aber was sagst du?
hinzugefügt der Autor Shizam, Quelle
Diese Antwort muss die Idee (n) präsentieren, die angeblich in klarerem Englisch präsentiert wird. Es scheint, dass die Kernidee der Antwort darin besteht, dass kleinere Klassen mit jeweils einer genau definierten Funktionalität eine gute Idee sind, aber die schreckliche Grammatik macht es fast unmöglich, sie zu verstehen. Diese Behauptung allein ist möglicherweise nicht ausreichend.
hinzugefügt der Autor Stefan Kendall, Quelle
@Deduplicator Nehmen wir ein Beispiel in Java, wenn wir entwerfen, dass wir Jframes-Threads und -Klassen für ihre Vererbung verwenden. Von nur einer Klasse können wir einige Java-Werke nicht für das Design verwenden. Daher müssen wir mehr Klassen erstellen
hinzugefügt der Autor David Farrell, Quelle

Die bisherigen Antworten, alle gut, haben mit der vernünftigen Annahme begonnen, dass dem Fragesteller etwas fehlt, was der Fragesteller auch anerkennt. Es ist auch möglich, dass der Fragesteller grundsätzlich recht hat, und es lohnt sich zu diskutieren, wie diese Situation entstehen kann.

Erfahrung und Praxis sind mächtig, und wenn die Senioren ihre Erfahrung in großen, komplexen Projekten sammeln, bei denen die einzige Möglichkeit besteht, die Dinge mit einer Menge von EntityTransformationServiceImpl zu kontrollieren, dann werden sie schnell und bequem im Design Muster und enge Einhaltung der DDD. Sie wären bei einem leichtgewichtigen Ansatz selbst bei kleinen Programmen viel weniger effektiv. Als das eine oder andere, sollten Sie sich anpassen und es wird eine großartige Lernerfahrung sein.

Während Sie sich jedoch anpassen, sollten Sie es als eine Lektion in Bezug auf das Gleichgewicht zwischen dem Erlernen eines einzelnen Ansatzes und dem Punkt, an dem Sie ihn überall einsetzen können, betrachten, anstatt vielseitig zu bleiben und zu wissen, welche Tools verfügbar sind, ohne unbedingt ein Experte bei einem von ihnen zu sein. Beides hat Vorteile und beides wird in der Welt benötigt.

2
hinzugefügt