Wie man Produktion und Modellklasse richtig trennt

Question

Ich habe GPS-Leser-Klasse, die Koordinaten von einem GPS-Empfänger liefert. Dies funktioniert natürlich bei Maschinen mit echten Empfängern. Jetzt habe ich eine Mockup-Klasse erstellt, die mir zufällig Koordinaten gibt, damit ich meine Anwendung starten und sehen kann, ob alles funktioniert, ohne sie auf einem anderen Rechner einsetzen zu müssen.

Nun ist dies die Struktur:

class AbstractGPSReader { 
} 

class RealGPSReader extends AbstractGPSReader { 
} 

class FakeGPSReader extends AbstractGPSReader { 
} 

class SomeOtherClass { 
    private AbstractGPSReader gpsReader = new RealGPSReader(); 
} 

Um in der Lage sein, um die Anwendung zu testen ich

new RealGPSReader() 

mit

new FakeGPSReader() 

Gibt es eine elegantere Möglichkeit ersetzen? Kann ich verhindern, dass jemand diese Klasse in der Produktion verwendet?

Answer 1

Sie sollten dependency injection verwenden. Es ist ziemlich einfach: Klassen sollten Instanzen ihrer Abhängigkeiten gegeben werden, anstatt die Abhängigkeiten selbst zu erstellen.

Zum Beispiel:

class SomeOtherClass { 
    private final AbstractGPSReader gpsReader = new RealGPSReader(); 
} 

wird zu:

class SomeOtherClass { 
    private final AbstractGPSReader gpsReader; 
    public SomeOtherClass(AbstractGPSReader gpsReader) { 
     this.gpsReader = gpsReader; 
    } 
} 

Der Vorteil hierbei ist, dass jetzt nur SomeOtherClassAbstractGPSReader gekoppelt ist, während es vorher zu AbstractGPSReader und RealGPSReader gekoppelt wurde.

Dies ist ein großer Vorteil, wenn Komponententests schreiben, weil jetzt kann die Klasse durch eine Testsuite unmodifizierten verwendet werden:

void testSomeOtherClass() { 
    SomeOtherClass someOtherClass = new SomeOtherClass(new FakeGPSReader()); 
    someOtherClass.someMethod(); 
    // etc... 
} 

Es gibt Rahmenbedingungen, die Sie die Injektion von Abhängigkeiten automatisiert helfen kann, aber ich würde vorschlagen, auf denen zu halten, um die Einfachheit des Codes zu bewahren.

---

Nebenbei sollten Sie versuchen, Ihre API um Schnittstellen statt abstrakte Klassen zu bauen.