Null-Objektmuster und Eingabevalidierung - echte Implementierung kopieren oder alles stillschweigend akzeptieren?

Ich habe ein WifiComponentin meinem Camerain meiner Client - Anwendung. Es ist für die Verwaltung der Wifi-bezogenen Funktionen der Kamera verantwortlich. Die Kamera repräsentiert eine reale Kamera.

Dies WifiComponentkann entweder aktiviert werden (in diesem Fall kann ich Dinge damit tun, z. B. den Verbindungsstatus überprüfen und scannen) oder deaktiviert werden (in diesem Fall können Sie überhaupt nichts damit tun, außer zu fragen, ob es aktiviert ist).

Beim Erstellen einer Camerain meinem Client verwendeten Anwendung frage ich die Kamera, ob sie WifiComponentaktiviert ist. Dann konstruiere ich die entsprechende Unterklasse von WifiComponententweder WifiComponentImploder NullWifiComponent.

Die Implementierung der supportedWifiTypes()und wifiScan()-Methoden ist einfach. Das NullWifiComponentunterstützt keine Typen, ist sofort mit dem Scannen fertig und findet keine Ergebnisse.

Aber jetzt muss ich eine bool connect(WifiNetwork network, String password)Methode implementieren . Ich möchte sagen, dass ich keine Verbindung hergestellt habe ... Aber ich unterstütze nicht einmal die WifiEncryptionTypeim WifiNetwork! Die eigentliche Implementierung löst IllegalArgumentExceptionein nicht unterstütztes WifiEncryptionTypeWLAN-Netzwerk aus, wenn Sie es übergeben .

Muss ich ...

Werfen IllegalArgumentException, weil ich die WifiEncryptionTypeangeforderte nicht unterstütze ?
return falseKeine Verbindung herstellen ( ), egal was bereitgestellt wird?

Verallgemeinerte Frage:

Wenn die tatsächliche Implementierung einen Vertrag erfüllt und ein Teil dieses Vertrags darin besteht, Ausnahmen für bestimmte Eingaben auszulösen, sollte eine Nullimplementierung ihre Neutralität oder den Vertrag priorisieren?

design design-patterns null

— Pimgd
quelle

Aus einem streng logischen POV könnte man sagen, dass Ihre Kamera das nicht ablehnt, da Sie keine Kamera haben, WifiEncriptionTypeso dass sie das nicht werfen sollte IllegalArgumentException. Ich denke also nicht, dass es eine Vertragsverletzung wäre, wenn man es nicht wirft.

— SJuan76

Ich habe eine Kamera, die Wifi über meine API einfach nicht unterstützt, entweder weil sie nicht in der Kamera in der Geräte-API implementiert ist oder weil die Kamera wirklich keinen Wifi-Adapter hat. Ich verstehe Ihren Standpunkt.

— Pimgd

Brechen Sie niemals den Vertrag einer Klasse. Ihre Fähigkeit, darüber nachzudenken, was ein Programm tut, hängt davon ab, dass jede Komponente das tut, was sie sagt. Manchmal müssen Sie den Vertrag oder das Gesamtdesign ändern, um das zu tun, was Sie wollen, aber niemals den Vertrag brechen.

— Doval

Aber warum können Sie den Vertrag nicht einfach erfüllen, um die Situation von WLAN mit Behinderung abzudecken? In diesem Fall werfen Sie einfach eine WifiDisabledException aus (z. B. die Erweiterung von IllegalStateException). Dadurch kann der Client-Code eine solche Situation erkennen und korrekt darauf reagieren (z. B. mit der richtigen Anzeige).

— Lorus

@lorus daran hatte ich nicht gedacht.

— Pimgd

Da die Null-Implementierung ein Ersatz für die voll funktionsfähige Implementierung sein soll, sollte die Null-Implementierung vollständig an der von ihr implementierten Schnittstelle haften.

Wenn die WifiComponentSchnittstelle angibt, dass connect()eine Ausnahme ausgelöst wird WifiEncryptionType, wenn sie mit einer nicht unterstützten aufgerufen wird, sollte Ihre Null-Implementierung genau dies tun, insbesondere wenn die Anwendung dieselbe WifiComponentSchnittstelle verwenden muss, um zu erfahren, welche WifiEncryptionTypes unterstützt werden.

Wenn die Liste der unterstützten WifiEncryptionTypes nicht aus Ihrer Null-Implementierung stammt, sollte Ihre Null-Implementierung nur dann eine Ausnahme auslösen, wenn auch eine funktionale Implementierung erforderlich ist, um sie auszulösen.

Wenn die WifiComponentSchnittstelle nicht angibt, dass eine Ausnahme ausgelöst werden muss, ist es besser anzunehmen, dass der Wert für eine funktionale Implementierung akzeptabel ist, und einen generischen Verbindungsfehler zu melden ( return false).

— Bart van Ingen Schenau
quelle

Ich darf die Benutzeroberfläche von WifiComponent ändern, suche aber nach einem Gleichgewicht zwischen nicht schwer zu handhabendem Arbeiten und der Bereitstellung von Fehlern, sobald Sie etwas tun, das nur schief gehen kann. Ich denke, das Auslösen der Ausnahme wäre der richtige Weg, da es ein Entwicklerfehler ist, einen nicht unterstützten Verschlüsselungstyp zu übergeben , und die Verwendung des Nullobjektmusters die Nullbehandlung und nicht die Vertragsnutzung vereinfacht.

— Pimgd

@pimgd Ich stimme dir hier zu. Es ist eindeutig ein Programmlogikfehler, wenn ein Verschlüsselungstyp angegeben wird, der nicht aus der Liste der unterstützten Typen stammt. Daher ist das Auslösen der Ausnahme definitiv die beste Option.

— Jules

@Pimgd: Wenn WifiComponent noch nicht in Stein gemeißelt ist, würde ich empfehlen, dass Sie zuerst einen sinnvollen Vertrag dafür definieren und dann Ihre Null-Implementierung mit der absoluten absoluten Mindestfunktionalität erstellen, die nicht gegen den von Ihnen festgelegten Vertrag verstößt.

— Bart van Ingen Schenau