Welche Klassenstruktur ist wünschenswerter?

Question

Ich bin nicht sicher, welches dieser beiden "Muster" das Beste ist. Derzeit verwende ich Option A (in Verbindung mit einem Provider für die Implementierung von Persistenz), aber ich bin jetzt auf dem Weg zu B, besonders im Hinblick auf Komponententests, die das "dependency injection" -Modell verwenden können.

Option A:

class ClassA 
{ 
    ClassA() { } 
    Save(); 
    static List<ClassA> GetClassAs(); 
}  

Option B:

class ClassA 
{ 
    ClassA() { } 
    Save(); 
} 

class ClassARepository 
{ 
    ClassARepository() { } 
    List<ClassA> GetClassAs();  
} 

Ich denke, was ich frage, ist es eine gute Übung für eine Klasse statische Methoden zu machen, die Rückkehr Sammlungen von Instanzen von sich selbst?

bearbeiten

Es scheint, dass Option B ist die bessere Wahl ein allgemeiner Konsens zu sein. Sieht so aus, als hätte ich eine Menge Refactoring im Voraus: S

Answer 1

Option B sieht ein wenig wie das ActiveRecord Muster aus (ich nehme an, die Save-Methode in ClassA wird das ClassARepository verwenden?), Was in manchen Situationen gut ist, aber wenn Sie ein ziemlich komplexes Domänenmodell haben, würde ich nicht Verwenden Sie das ActiveRecord-Muster.

Stattdessen würde ich ein solches Modell verwenden:

public class ClassA 
{ 
    public int Id {get; private set;} 
    public string Name {get; set;} 
} 

public class ClassARepository 
{ 
    public ClassA Get(int id); 

    public void Save(ClassA item); 
} 

Was bedeutet, dass alle Persistenz bezogene Logik in der ClassARepository Klasse gesetzt wird, und KlasseA hat auch keinen direkten Zugriff auf das Repository.

Answer 2

Sie teilen entweder die vollständige Persistenz des Objekts von den Daten und der Logik oder behalten alle in der einen Klasse. Verschieben Sie 'Speichern' in 'ClassARepository' oder behalten Sie 'GetClassAs' in 'ClassA'.

Answer 3

Nein, ich würde diese schlechte Praxis nicht als eine harte und schnelle Regel betrachten, obwohl ich annehme, dass dies für eine Art von Instanzverfolgung oder Ressourcenüberwachung ist? Wenn ja, denken Sie daran, dass hinter den Kulissen Logik sein muss, um sicherzustellen, dass Objekte, die sonst nicht in Reichweite wären, nicht nur in Ihrer statischen Sammlung bleiben. Ich bin mir nicht sicher, welche Sprache Sie verwenden, aber wenn es C# ist, können Sie es intern als List<WeakReference> speichern.

Answer 4

Option B sieht besser aus, weil A zwei Ideen, zwei Arten von Funktionalität mischt. Es gibt die eigentliche Funktion der A-Klasse und die separate Funktion, die Sammlung von A zu verwalten.

Da die Anwendung wächst, ist es auch wahrscheinlich, dass Sie zusätzliche Funktionen in Ihrem Repository benötigen - findById, Abrufen von Teilmengen usw.etc. Shoe Horning dies in die A-Klasse wird chaotisch.

Und wie Sie bemerkt haben, ist Option B einfacher zu testen.

Answer 5

Option B ist flexibler.

• Es ermöglicht die Möglichkeit, mehrere Repositories zu haben.
• Ermöglicht die Unterklasse der Repository-Klasse.
• Es ermöglicht Ihnen, das Repository als Argument an eine andere Klasse oder Funktion zu übergeben, anstatt diese Klasse oder Funktion explizit an eine globale statische Variable gekoppelt zu haben.

Answer 6

Ich denke, was ich bin gefragt, ist es eine gute Übung für eine Klasse statische Methoden zu machen, die Sammlungen von Instanzen von sich selbst zurückkehren?

Allgemeinen keine - solche Sammlungen sind oft Singletons, und wenn sie (wie in Ihrem Beispiel) sind dann die üblichen Gründe für Singletons ein antipattern betrachtet wird, sowie die Gründe, die static is considered harmful.