Im Allgemeinen finde ich das sehr oft. Einige meiner Mitarbeiter bevorzugen sehr einfache, leicht zu lesende Klassen, auch wenn dies eine gewisse Codeverdoppelung bedeutet, während ich alles in meiner Macht stehende tue, um Code-Duplikation zu vermeiden, auch wenn das bedeutet, eine komplizierte Architektur zu erstellen. Was ist die beste Praxis? Ich arbeite ausschließlich in Java.
Obwohl beide gute Ziele sind, halte ich die Lesbarkeit für die erste Voraussetzung für eine wartungsfähige Codebasis. Ich würde immer einfach, lesbar und wartbar zu einer vollständigen Beseitigung der Code-Duplikation bevorzugen.
Bewährte Methode: Wenn der Code kurz ist, duplizieren Sie ihn zweimal, aber nie mehr.
Wenn Sie also sehr ähnliche Codeschnipsel an drei verschiedenen Stellen kopieren / einfügen, sollten Sie ein Refactoring in Erwägung ziehen.
Denken Sie daran, dass Refactoring nicht automatisch bedeutet, dass Code komplizierter wird. Berücksichtigen Sie Folgendes:
%Vor%Immer wenn Sie einen Stack für einen neuen Datentyp benötigen, müssen Sie eine neue Klasse schreiben. Duplizieren von Code funktioniert gut, aber nehmen wir an, Sie möchten eine neue Methode hinzufügen, vielleicht eine "Push" -Methode, die einen neuen Stapel zurückgibt? In Ordnung, jetzt musst du es an vielen verschiedenen Orten hinzufügen. Oder Sie könnten einen generischen Objektstapel verwenden, aber dann würden Sie die Typensicherheit verlieren. Generics werden die Architektur vereinfachen:
%Vor%Cool!
Okay, wie wäre es mit diesem Beispiel:
%Vor%Also, jedes Mal, wenn Sie eine Methode hinzufügen, müssen Sie überprüfen, welche Art von Logger Sie verwenden. Schmerzhaft und anfällig für Fehler. Normalerweise würden Sie eine Schnittstelle ausrechnen (wahrscheinlich mit den Methoden Log, Clear und Truncate) und dann drei Klassen erstellen (FileLogger, DatabaseLogger, ConsoleLogger).
Mehr Klassen = mehr Architektur. Ist dies auf längere Sicht leichter oder schwerer zu halten? Für dieses Beispiel würde ich sagen, dass der Code jetzt einfacher zu pflegen ist, aber YMMV.
Der Hauptgrund für die Vermeidung von Code-Duplizierung ist die Wartbarkeit. Wenn ein Codeabschnitt an mehreren Stellen angezeigt wird, müssen Sie sich daran erinnern, ihn zu allen Zeiten zu ändern, überall . Wenn Sie vergessen, eine Instanz zu ändern, können große Probleme auftreten, die Sie möglicherweise nicht sofort bemerken.
Es gibt extreme Fälle, in denen Sie Code-Duplikation durch komplizierte Metaprogrammierung verhindern (nicht so sehr ein Problem für Java) oder exzessive Verwendung von Reflektion, und in diesen wenigen Fällen würde ich die Duplizierung bevorzugen. Das ist selten. Solange der Code von einem vernünftigen Entwickler, der nicht Sie ist, verständlich bleibt, würde ich die Duplizierung beseitigen.
Ich bin über Situationen gestolpert, in denen ein Team ein oder zwei fähige Entwickler und ein paar Neulinge umfasst, wo die Neulinge versuchen, die Verwendung von Codierungsansätzen zu verhindern, die sie auf den ersten Blick nicht verstehen. Dies muss widerstanden werden.
Ich sehe nicht, wie "Generika" mit Ihrer Frage zusammenhängen. Es ist trivial, offensichtlich falsch, getrennte Klassen zu haben, um eine CollectionOfFoo und eine CollectionOfBar zu repräsentieren, also kann das nicht das sein, was du fragst.
Sie müssen wahrscheinlich für jeden Standpunkt ein Beispiel angeben, aber Sie werden wahrscheinlich trotzdem geschlossen, weil Sie subjektiv sind.
Dies ist ein Urteilsspruch. Die meisten Programmierer kopieren Code zu sehr, und ich denke, das führt zu der Einstellung unter leidenschaftlichen Entwicklern, dass das Ausrotten von Duplikaten absolut gut ist, aber das ist es nicht. Es sollte Priorität haben, den Code leicht lesbar zu machen, und das Entfernen von doppeltem Code ist in der Regel eine gute Sache für die Lesbarkeit, aber nicht immer.
Außerdem würde ich kommerziell wertvollen Code nicht als einen Platz verwenden, um unbekannte Sprachmerkmale zu dem Zweck zu verwenden, sie zu lernen. Erstellen Sie separate Lernprojekte für diesen Zweck. Sie wollen nicht am Abend in die Arbeit gerufen werden, um Bugs zu beheben, die dadurch verursacht werden, dass Sie mit Generika oder anderen Features zu extravagant werden.
Die Vermeidung von Code-Duplikaten ist immer eine gute Sache. Die einzige Sache, gegen die Sie sich schützen müssen, ist Vorzeitige Generalisierung .
Es gibt keine Notwendigkeit, in Eile zu kommen, da Sie ein paar Code-Teile erhalten, die ähnlich aussehen. Es ist in Ordnung, sich zurückzulehnen, bis Sie ein gutes Modell entwickelt haben.
Sogar ein paar Beispiele von Dingen, die Sie verallgemeinern müssen, können in Ordnung sein, besonders wenn Dinge etwas komplexer und / oder offen sind. Es kann einfacher sein zu verallgemeinern, wenn Sie 3-5 + Beispiele haben, anstatt nur ein oder zwei.
Nein. Keine dieser Situationen ist akzeptabel. Schreiben Sie es mit Generika, aber nur so komplex wie es sein muss.
Kopieren Sie den Code nicht. Sie müssen Bugs doppelt beheben, Erweiterungen doppelt hinzufügen, Kommentare doppelt schreiben, Tests doppelt schreiben. Jede Codezeile, die Sie erstellen, ist eine kleine Last, die Sie tragen müssen, solange Sie an dieser Codebasis arbeiten. minimieren Sie Ihre Belastung.
Hängt von einer Reihe von Faktoren ab:
Also meine Antwort ist vielleicht ...
Bevor ich meine Antwort gebe, möchte ich einen Beispielcode sehen, um zu sehen, was die Frage wirklich ist.
Während ich darauf warte, glaube ich, dass, wenn Ihr Code in den meisten vernünftigen OO-Prinzipien (wie jede Klasse macht nur eins und nur eins ) gebaut wird, sollte es keinen Code geben Duplikation herum. Es ist sicherlich möglich, sich mit Abstraktionen usw. zu beschäftigen, die am Ende einen riesigen Haufen nutzloser Klassen schaffen, aber ich glaube nicht, dass das hier das Thema ist.
Der Hauptgrund, warum Generika schwer zu lesen sind, liegt darin, dass es unerfahrenen Programmierern unbekannt ist. Dies bedeutet, dass bei der Wahl der Benennung und Dokumentation größte Sorgfalt walten muss, um Klarheit zu schaffen.
Es ist äußerst wichtig, dass solche Kernklassen gut benannt sind. Der Designer möchte dies vielleicht mit Gleichgesinnten gründlich besprechen, bevor er die Namen auswählt.
Ausgezeichnete Frage; Die allgemeinen Antworten passen möglicherweise nicht zu Ihrer Situation. Es gibt viele Faktoren entscheidet Ihre Wahl
Dies sind einige der entscheidenden Faktoren, die Ihre Entscheidung entscheiden. Nach meiner Erfahrung bin ich der Meinung, dass doppelte Geschäftslogik (mittlere Stufe) keine gute Übung ist, aber die Präsentationsebene kann doppelte Codes haben.
Wenn ich das schreibe, erinnere ich mich an den Artikel " Ist langsames Wachstum gleich Tod ". Das Schreiben von Qualität und nicht doppeltem Code kann einige Zeit in Anspruch nehmen, aber das sollte kein Engpass für Ihr Unternehmen sein.
Normalerweise besteht der einzige Grund, Code zu duplizieren, darin, das schwache Template / Makro / Generics-System einer Sprache zu überwinden oder für die Optimierung, wo es verschiedene Low-Level-Funktionsnamen gibt, die unterschiedliche Typen behandeln.
In C ++, in dem Sie angegeben haben, dass nicht funktioniert, ermöglicht das Vorlagensystem die Erstellung von Null-Overhead-Typen und -Funktionen, wobei Spezialisierung zur Verfügung steht generierter Code für bestimmte Typparameter. Java hat nichts von dieser Art und beseitigt die in C ++ verfügbare Auswahlmöglichkeit, die sowohl allgemein als auch spezifisch ist.
In Common Lisp kann man Makros und Compiler-Makros verwenden, um Code ähnlich wie C ++ - Vorlagen zu erzeugen, wobei grundlegende Fälle für bestimmte Typen angepasst werden können, was zu verschiedenen Code-Erweiterungen führt.
In Java würde ich nur gegen innere Schleifen argumentieren, die numerische Typen verwenden. Die Boxing- und Unboxing-Kosten für numerische Typen in generischem Code zu bezahlen, ist in diesen Fällen inakzeptabel, es sei denn, dein Profiler kann dich davon überzeugen, dass der Compiler oder HotSpot clever genug war, um auf das Boxen zu verzichten.
Was die Lesbarkeit angeht, machen Sie Ihren Code zum Modell und zur Herausforderung, der sich Ihre Mitarbeiter stellen müssen. Angebot für diejenigen, die Schwierigkeiten haben, es zu lesen. Ermutigen Sie sie, sie auf Mängel zu überprüfen. Wenn sie welche finden, können Sie den Vorteil demonstrieren, dass Sie nur die einzige Version reparieren müssen.
Vergleichen Sie es mit Normalisierung in relationalen Datenbanken - Sie wollen wahrscheinlich einen Ort, wo eine Art von Funktion oder Daten lebt, nicht viele Orte. Es macht einen großen Unterschied in Bezug auf Wartbarkeit und die Fähigkeit, über Ihren Code nachzudenken.
Tags und Links java generics code-duplication