Patrón de objeto nulo y validación de entrada: ¿copiar la implementación real o aceptar todo silenciosamente?

Tengo un WifiComponenten mi Cameraaplicación en mi cliente. Es responsable de manejar la funcionalidad relacionada con Wifi de la cámara. La cámara representa una cámara del mundo real.

Esto WifiComponentse puede habilitar (en cuyo caso puedo hacer cosas con él, como verificar el estado de la conexión y escanear) o deshabilitar (en cuyo caso no puede hacer nada con él, aparte de preguntar si está habilitado).

Al crear una aplicaciónCamera en mi cliente , le pregunto a la cámara si WifiComponentestá habilitada. Luego construyo la subclase apropiada de WifiComponent, ya sea WifiComponentImplo NullWifiComponent.

Implementar los métodos supportedWifiTypes()y wifiScan()es fácil. El NullWifiComponentno admite ningún tipo, se realiza instantáneamente con el escaneo y no encuentra resultados.

Pero ahora tengo que implementar un bool connect(WifiNetwork network, String password)método. Quiero decir que no pude conectarme ... ¡Pero ni siquiera soporto lo WifiEncryptionTypeprovisto en el WifiNetwork! La implementación real arroja un IllegalArgumentExceptionsi pasa una WifiEncryptionTypered wifi no compatible .

¿Yo ...

Lanzar IllegalArgumentException, porque no apoyo lo WifiEncryptionTypesolicitado?
Silenciosamente no se conecta ( return false), sin importar lo que se proporcione?

Pregunta generalizada:

Si la implementación real cumple con un contrato, y parte de este contrato es lanzar excepciones para ciertas entradas, ¿una implementación nula debe priorizar su neutralidad o el contrato?

design design-patterns null

— Pimgd
fuente

Desde un punto de vista estrictamente lógico, se podría decir que, dado que no tiene cámara, su cámara no rechaza la, WifiEncriptionTypepor lo que no debe arrojarla IllegalArgumentException. Por lo tanto, no creo que arrojarlo sea un incumplimiento de contrato.

— SJuan76

Tengo una cámara, simplemente no es compatible con Wifi a través de mi API, ya sea porque no está implementada en la cámara en la API del dispositivo o porque la cámara realmente no tiene un adaptador Wifi. Sin embargo entiendo lo que quieres decir.

— Pimgd

Nunca rompas el contrato de una clase. Su capacidad de razonar sobre lo que hace un programa depende de que cada componente haga lo que dice que hace. A veces necesita cambiar el contrato o el diseño general para hacer lo que desea, pero nunca romper el contrato.

— Doval

Pero, ¿por qué no puede cumplir el contrato para cubrir la situación de la discapacidad wifi? Simplemente arroje un poco de WifiDisabledException (digamos, extendiendo IllegalStateException) en este caso. Esto permitirá que el código del cliente reconozca dicha situación y responda correctamente (por ejemplo, con la indicación adecuada).

— lorus

@lorus No había pensado en eso.

— Pimgd

Como se supone que la implementación nula es un reemplazo directo para la implementación funcional completa, la implementación nula debe adherirse completamente a la interfaz que implementa.

Si la WifiComponentinterfaz especifica que connect()arroja una excepción si se invoca con una no admitida WifiEncryptionType, entonces eso es exactamente lo que debe hacer su implementación nula, especialmente si la aplicación debe usar la misma WifiComponentinterfaz para saber cuáles WifiEncryptionTypeson compatibles.

Si la lista de WifiEncryptionTypes admitidos no proviene de su implementación nula, entonces su implementación nula solo debería lanzar una excepción si también se requiere una implementación funcional para lanzarla.

Si la WifiComponentinterfaz no especifica que se debe lanzar una excepción, entonces es mejor asumir que el valor sería aceptable para una implementación funcional e informar una falla de conexión genérica ( return false).

— Bart van Ingen Schenau
fuente

Se me permite modificar la interfaz de WifiComponent, pero estoy buscando un equilibrio entre no ser difícil de trabajar y proporcionar errores en el momento en que haces algo que solo puede salir mal. Creo que lanzar la excepción sería el camino a seguir porque es un error del desarrollador pasar un tipo de cifrado no compatible , y el uso del patrón de objeto nulo es simplificar el manejo nulo, no simplificar el uso del contrato.

— Pimgd

@pimgd Estoy de acuerdo contigo aquí. Es claramente un error lógico del programa si se especifica un tipo de cifrado que no proviene de la lista de tipos admitidos, por lo que arrojar la excepción es definitivamente la mejor opción.

— Jules

@Pimgd: Si WifiComponent aún no está establecido, recomendaría que primero defina un contrato razonable para él y luego cree su implementación nula con la funcionalidad mínima absoluta absoluta que no viola el contrato que ha establecido.

— Bart van Ingen Schenau