2009-07-20 7 views
0

Für das letzte Jahr oder so habe ich die Idee verfolgt, dass wenn eine Methode statisch sein könnte, um es statisch zu machen, da dies einen Leistungsvorteil haben kann, und ich daher mit einigen gelandet bin statische Klassen in meinen Anwendungen.Alternative zur statischen Klasse für zustandslose Objekte

Ich habe gelernt, die Leistung Vorteil ist nicht oft groß genug, um sich zu lohnen, und auch die Unterscheidung, dass Methoden, die statisch gemacht werden können, vielleicht nicht aus einem Design-Sicht, wenn sie spezifischer sind das Objekt und nicht den Typ - related question

Als Beispiel habe ich kürzlich eine FileRepository-Klasse erstellt, die das Repository-Muster für unsere eigene File-Klasse implementiert (zum Beispiel Import-Dateien). Diese Klasse ist nicht statisch und ein Repository-Objekt muss erst erstellt werden, bevor auf es zugegriffen werden kann.

Mein Problem mit diesem, sind alle meine alten statischen Aufrufe, sind jetzt 2 Zeilen (es sei denn, ich kann das Objekt im lokalen Bereich wiederverwenden). Das Repository-Objekt hat (bis jetzt) ​​keinen Status, da es den Datenbankzugriff über eine statische Thread-Variable verwendet.

Meine Frage ist, was sind die Meinungen der Menschen über einen Thread statische aktuelle Eigenschaft auf der Klasse, wo der Zugriff Accessor initialisiert das Objekt beim ersten Aufruf? So wie ich es verstehe, würde dies immer noch die Fallstricke von statischen Klassen vermeiden, wie zum Beispiel nicht in der Lage sein, generische Funktionalität über Schnittstellen zu implementieren, aber dennoch die Leichtigkeit von Ein-Zeilen-Aufrufen für das Repository-Objekt bieten?

Nur versuchen, meine Praktiken und Denkweise zum Besseren anzupassen.

+0

Tangens: FileRepository sollte nicht zustandslos sein. FileRepository sollte EXPLICITLY von der Datenbank abhängen. I.e. Sein Konstruktor sollte eine Datenbank aufnehmen (und sie in einer Member-Variablen speichern). Ohne Status lügt FileRepository über die Abhängigkeiten, die es hat.Dies macht es schwierig, Tests zu schreiben, weil man nicht einfach eine Pseudo-Datenbank geben kann; Sie haben eine echte Datenbank eingerichtet und lassen Sie diese verwenden. Die Einrichtung einer echten Testdatenbank ist nicht nur mühselig, sondern wird Ihren Test wahrscheinlich auch verlangsamen. Warum hasst du dein zukünftiges Selbst: P – allyourcode

Antwort

5

Statik kann die Testbarkeit beeinträchtigen.

Insbesondere wird es relativ schwierig sein, alles zu testen, das das Repository verwendet. Anstatt bei jedem Aufruf ein neues Repository zu erstellen, sollte es Teil des Status von allem sein, was es erfordert. Verwenden Sie Dependency Injection, um das Repository bereitzustellen, das eine entsprechende Schnittstelle implementiert. Sie können dann alles, was das Repository verwendet, durch Mock-out testen.

Natürlich ist dies eine ideale Lösung, die vielleicht nicht die pragmatische Lösung für Ihren Fall ist - aber im Allgemeinen objektorientiert.

Sie könnte das "aktuelle" Repository haben und noch einigermaßen testbar sein, aber es erfordert immer noch statischen Zustand, der im Allgemeinen verpönt ist. Es ist ein leichter Code-Geruch, aber es wäre zumindest besser als die statischen Methoden.

+0

Wow! Dies ist das erste Mal, dass ich ** 1 Sek. ** Unterschied zwischen zwei Antworten sehe. –

1

Ein Vorteil von nicht mit statischen Sachen und immer direkte Verweise auf Abhängigkeiten ist die Fähigkeit, Testobjekte leicht zu verspotten und zu vereinigen. Sie verlieren diese Fähigkeit, wenn Sie direkt auf Ihre statische Klasse oder Ihre aktuelle Eigenschaft verweisen.

0

Sie müssen erklären, über welche Leistungseinbußen Sie sprechen. Sprechen wir Mikrosekunden?

Häufig kann die Anwendungsleistung verbessert werden, indem ein Profiler ausgeführt und der entsprechende Code gefunden wird. Sehen Sie sich den ANTS-Profiler als Beispiel an.

Allzu oft finde ich Datenbankzugriff der Schuldige 70% der Zeit.

Verwandte Themen