Code-Wiederverwendung in Methods.class vs Strategie Muster und Abhängigkeitsinjektion

Ihre Frage hat eigentlich zwei Bedeutungen.

  

das in vielen Klassen viele Male wiederverwendet werden muss

Dies kann ein Kontext von Entwurfsmustern (wiederverwendbare Komponente) oder Speicherkosten (Klasseninstanziierung) sein. Aus zwei verschiedenen Perspektiven sprechen:

Speicherkosten (Ich hatte wenig Erfahrung damit, aber lassen Sie mich meine Erfahrung teilen)

Dieser Abschnitt behandelt eigentlich nur zwei Arten von Instanziierung.

Zuerst ist statisch (oder DI-Instanziierung im Kompositionswurzel)

• Eager instanziation bedeutet, dass alle Klassen beim Start der Anwendung instanziiert werden
• Nur einmalige Instanziierung

Nicht statisch

• Faule Instanziierung bedeutet, dass die Klasse nur bei Bedarf instanziiert wird
• Einmalige Instantiierung jeder Verwendung

Kurz gesagt: Statische Kosten sind hoch, wenn die Klasse viele ist, und nicht-statische Kosten sind hoch, wenn die Anfrage hoch ist (zum Beispiel für for-Schleife). Aber es sollte Ihre Bewerbung nicht schwer machen. Die meisten Operationen in java / csharp sind jedoch Objekte erstellen.

Klassenwiederverwendbarkeit

1 - mega monolithischer Code (eine Gottklasse, die fast alles kann)

Vorteile:

1. Einfach nach Code zu suchen (hängt immer noch davon ab), Sie wissen, dass jede Logik dort liegt, also müssen Sie sich nur diese große Klasse ansehen
2. Wenn es statisch ist, können Sie es einfach überall aufrufen, ohne sich Gedanken über die Instanziierung machen zu müssen

Nachteile:

1. Jede Änderung für eine Methode erzeugt ein Risiko für Fehler an anderen Stellen
2. Verletzung von SRP bedeutet, dass diese Klasse aus verschiedenen Gründen geändert werden kann, nicht nur ein
3. Insbesondere in der Versionierung ist es schwieriger zu verschmelzen, wenn die Änderung in getrennten Zweigen erfolgt, was zu einem Aufwand bei der Synchronisierung von Code führt

1a / statische Klasse / Singleton-Muster

Vorteile:

1. Einfach zu verwenden
2. Kann überall verwendet werden (nur referenzieren und aufrufen, und fertig)
3. Das Objekt muss nicht instanziiert werden

Nachteile:

1. Es ist schwierig, einen Unit-Test durchzuführen (es ist schwer nachzuahmen, und zu einem späteren Zeitpunkt wird es Zeit brauchen, die Testumgebung vorzubereiten. Besonders mit Daten
2. Wenn stateful (hat Zustand), ist es schwierig, den aktuellen Zustand während des Debuggens zu bestimmen. Darüber hinaus ist es schwierig zu bestimmen, welche Funktion den Zustand ändert, und kann von überall geändert werden (
)
3. Neigen dazu, viele Parameter zu haben (etwa 5-11)

Einige Punkte zur statischen Klasse: siehe diese Frage

2 Strategie-Muster

Eigentlich hat dies das gleiche Design mit 3 oder composition over inheritance .

3 Abhängigkeitsinjektion

Vorteile:

• Einfach zu simulieren und zu testen
• %Code%. Es ist einfacher zu debuggen und Komponententest, wenn die Klasse zustandslos ist
• Unterstützung, die umstrukturiert werden soll

Der Nachteil:

• Schwer zu debuggen für diejenigen, die mit den Schnittstellen nicht vertraut sind (jedes Mal, wenn Sie die Methode umleiten, geht es an die Schnittstelle)
• Erstellt eine Überlagerung, die zum Mapping führt

Staat / Staatenlos

Ich denke, dass Staaten wichtige Regeln in Ihrem Anwendungsdesign spielen. Normalerweise versuchen Entwickler, Zustände im Geschäftslogikcode zu vermeiden, wie zum Beispiel:

Entwickler neigen dazu, die Logik in andere Must be stateless -Klasse oder zumindest Methoden wie:

Es wird eine bessere Lesbarkeit bieten und einfacher für Modifizierungs- und Komponententests sein. Es gibt auch ein Entwurfsmuster stateless , um insbesondere solche Fälle zu behandeln.

Prinzip der einfachen Verantwortung

IMHO, dieses Prinzip hat den größten Nutzen, wenn es befolgt wird. Die Vorteile sind:

1. In der Versionierung sind die Änderungen klar darüber, welche Klasse geändert wurde und warum
2. In DI können mehrere kleinere Klassen verdrahtet werden, was sowohl bei der Verwendung als auch beim Komponententest für Flexibilität sorgt
3. Modularität, geringe Kopplung und hohe Kohäsion erhöhen

TDD (Test Driven Development)

Dieser Entwurf garantiert nicht, dass Ihr Code frei von Fehlern ist. Im Gegensatz zu Kosten für die Design-Phase und Layering-Aufwand hat es den Vorteil von:

1. Einfach zu testendes Objekt für Komponententest
2. Einfachere Refactoring aufgrund von Komponententest und Modularität
3. Leichter zu pflegen / zu erweitern

Einige nützliche Quellen

Anti-Pattern für Service Locator

Verwenden von Decorator als Querschnittsaufgabe

Meine 2 Cent:

Der Vorteil der Verwendung der Schnittstelle (gilt auch für die Zusammensetzung der Vererbung)

Top-down-Design / DI-Design

Abschließende Gedanken

Diese Designs und Strategien sind nicht der Schlüssel, der Ihre Anwendungsstruktur bestimmt. Es ist immer noch der Architekt, der es bestimmen wird. Ich bevorzuge es, einigen Prinzipien wie SOLID, KISS und GRASP zu folgen, anstatt zu entscheiden, was die beste Struktur ist. Es wird gesagt, dass Dependency Injection den meisten dieser Prinzipien folgt, aber zu viel Abstraktion und falsches Design der Komponenten führt zu dem Missbrauch von Singleton-Mustern.

  

1.a. Machen Sie Methoden statisch und rufen Sie (von allen Klassen und gleichzeitigen Threads) direkt als MyMethods.someMethod ();

auf      

1.b. Machen Sie Methoden nicht statisch und initialisieren Sie die gesamte Klasse zu dem Zeitpunkt, zu dem sie aufgerufen werden. MyMethods mm = MyMethods (); mm.someMethod ();

Die Wahl zwischen diesen beiden hängt von der Funktionalität von MyMethods.class ab. Wenn MyMethods zustandslos sein soll, dann ist es ein guter Ansatz, mit static Methoden zu gehen. Andernfalls, wenn ein Methodenaufruf von einem anderen abhängt und MyMethods über Zustände (d. H. Nicht endgültige Felder) verfügt, verwenden Sie die zweite Option.

  

Verwenden Sie das in Ссылка angegebene Strategie-Muster (Code hier beigefügt).

Verwenden Sie dieses Muster, wenn MyMethods mit verschiedenen Klassen für verschiedene Zwecke erweitert werden soll und Sie auswählen, welcher Code abhängig von Ihrem Kontext ausgeführt werden soll. Wie das Wiki sagt, wenn Sie den zu verwendenden Algorithmus vor der Laufzeit nicht kennen (hängt von einigen Bedingungen ab), ist dies der richtige Weg. Gemäß Ihrer Spezifikation von MyMethods haben Sie solche Probleme nicht.

  

Verwenden Sie die Abhängigkeitsinjektion, die unter Ссылка

angegeben ist

Gleiche Antwort wie oben. Die Sache mit Abhängigkeitsinjektion ist in Inversion der Kontrolle . Eine Klasse, die MyMethods verwendet, weiß nicht über die tatsächliche Implementierung von MyMethods , aber die Injektion der realen Implementierung wird an eine höhere Autorität delegiert. Es abstrahiert externe Abhängigkeiten aus dem Kontext, in dem es verwendet werden soll. Wenn MyMethods wieder zustandslos und konstant sein soll (nicht geplant, sich zu ändern, und das Verhalten der Methoden in der Klasse nicht vom Kontext abhängt, in dem sie verwendet werden), brauchen Sie diese Muster nicht, da dies nur Übertechnik bedeuten würde .

Ich würde daraus schließen, dass Sie das Strategie oder DI Muster verwenden sollten, wenn die Logik von MyMethods vom Kontext abhängt, aus dem sie ausgeführt werden. Wenn diese Konstante konstant ist (z. B. ob Javas Math -Klasse egal ist, wer oder in welchem ​​Kontext jemand sqrt() , max() oder pow() aufruft), dann sind statische Methoden die richtige Wahl.

Bei Problemen:

Probleme, die Sie angegeben haben, sind nicht vorhanden, wenn Sie MyMethods mit static Methoden verwenden. Sie müssen testen, ob Ihre Methoden korrekte Werte für bestimmte Argumente liefern, und das war's. Ich glaube nicht, dass es viel mehr Probleme beim Testen der tatsächlichen Implementierung von Strategy in Strategy pattern oder der Implementierung von Schnittstellen geben würde, die durch Dependency injection injiziert werden. Was vielleicht schwieriger ist, testet die Klassen, die die Strategie verwenden, weil es manchmal nicht einfach ist, den Kontext wiederherzustellen, in dem die bestimmte Strategie ausgeführt wird, da dies oft von Benutzereingaben abhängt, aber es ist definitiv nicht unmöglich. Die Abhängigkeitsinjektion ist meines Erachtens ideal zum Testen, da Sie die zu testende Einheit von einer Abhängigkeit trennen können, die Sie leicht verspotten können.