Validação de padrão de objeto nulo e entrada - copie a implementação real ou aceite tudo silenciosamente?

Eu tenho um WifiComponentno meu Cameraaplicativo no meu cliente. É responsável por lidar com a funcionalidade relacionada à Wifi da câmera. A câmera representa uma câmera do mundo real.

Isso WifiComponentpode ser ativado (nesse caso, eu posso fazer coisas com ele, como verificar o status e a verificação da conexão) ou desativado (nesse caso, você não pode fazer nada com isso, além de perguntar se está ativado).

Ao criar um Camerano meu aplicativo cliente , pergunto à câmera se ela WifiComponentestá ativada. Então eu construo a subclasse apropriada de WifiComponent, ou WifiComponentImplou NullWifiComponent.

A implementação dos métodos supportedWifiTypes()e wifiScan()é fácil. O NullWifiComponentnão suporta nenhum tipo, é feito instantaneamente com a verificação e não encontra resultados.

Mas agora eu tenho que implementar um bool connect(WifiNetwork network, String password)método. Quero dizer que não consegui conectar ... Mas eu nem apoio o WifiEncryptionTypefornecido no WifiNetwork! A implementação real lança um IllegalArgumentExceptionse você passar uma WifiEncryptionTyperede wifi não suportada .

Eu ...

Jogue IllegalArgumentException, porque eu não apoio o WifiEncryptionTypesolicitado?
Falha silenciosamente ao conectar ( return false), não importa o que for fornecido?

Pergunta generalizada:

Se a implementação real cumprir um contrato, e parte deste contrato for lançar exceções para determinadas entradas, uma implementação nula deve priorizar sua neutralidade ou o contrato?

design design-patterns null

— Pimgd
fonte

De um ponto de vista estritamente lógico, você poderia dizer que, como não possui câmera, sua câmera não rejeita a câmera e não a WifiEncriptionTypelança IllegalArgumentException. Portanto, acho que não jogá-lo seria uma quebra de contrato.

— precisa

Eu tenho uma câmera, ela simplesmente não suporta Wifi por meio da minha API, porque ela não está implementada na câmera na API do dispositivo ou porque a câmera realmente não possui um adaptador Wifi. Eu entendi o seu ponto.

— Pimgd

Nunca quebre o contrato de uma turma. Sua capacidade de raciocinar sobre o que um programa faz depende de cada componente fazer o que ele diz que faz. Às vezes, você precisa alterar o contrato ou o design geral para fazer o que deseja, mas nunca quebra o contrato.

— Doval

Mas por que você não pode apenas cumprir o contrato para cobrir a situação do wifi desativado? Basta lançar alguma WifiDisabledException (por exemplo, estendendo IllegalStateException) nesse caso. Isso permitirá que o código do cliente reconheça essa situação e responda a ela corretamente (por exemplo, com indicação adequada).

— Lorus

@lorus eu não tinha pensado nisso.

— Pimgd

Como a implementação nula deve substituir a implementação totalmente funcional, a implementação nula deve aderir totalmente à interface implementada.

Se a WifiComponentinterface especificar que connect()lança uma exceção se for invocada com uma incompatível WifiEncryptionType, é exatamente isso que sua implementação nula deve fazer, especialmente se o aplicativo precisar usar a mesma WifiComponentinterface para saber quais WifiEncryptionTypesão suportados.

Se a lista de WifiEncryptionTypes suportados não vier de sua implementação nula, sua implementação nula somente lançará uma exceção se uma implementação funcional também for necessária para lançá-la.

Se a WifiComponentinterface não especificar que uma exceção deve ser lançada, é melhor assumir que o valor seria aceitável para uma implementação funcional e relatar uma falha de conexão genérica ( return false).

— Bart van Ingen Schenau
fonte

Estou autorizado a modificar a interface do WifiComponent, mas estou procurando um equilíbrio entre não ser difícil de trabalhar e fornecer erros no momento em que você faz algo que só pode dar errado. Eu acho que lançar a exceção seria o caminho a seguir, pois é um erro do desenvolvedor passar em um tipo de criptografia não suportada , e o uso do padrão de objeto nulo é simplificar o tratamento nulo, não simplificando o uso do contrato.

— Pimgd

@ pimgd Eu concordo com você aqui. É claramente um erro de lógica do programa se for especificado um tipo de criptografia que não veio da lista de tipos suportados, portanto, lançar a exceção é definitivamente a melhor opção.

— Jules

@Pimgd: Se o WifiComponent ainda não estiver definido, recomendo que você primeiro defina um contrato sensato para ele e depois crie sua implementação nula com a funcionalidade mínima absoluta absoluta que não viola o contrato que você estabeleceu.

— Bart van Ingen Schenau