Cujo contrato (projeto por contrato) é melhor?

StackOverflow https://stackoverflow.com/questions/414264

Pergunta

Suponha que eu tenho um método 

public Patient(int id)
{
    ----
}

que retorna objeto Paciente dado um id .. Eu poderia definir contrato de 2 maneiras

  1. Método iria retornar nulo se o paciente não existe
  2. Método iria lançar uma exceção se o paciente não existe. Neste caso, eu também iria definir um método de consulta que retorna verdadeiro se a exist Paciente no banco de dados ou falso caso contrário ...

Qual contrato devo usar? Qualquer outra sugestão?

Update: comentário Por favor, neste caso também ... Se não for um banco de dados atribuído Id e é algo que um usuário entra na UI .. como SSN .. então qual é o melhor ..

Comentário sobre o padrão nulo de Steve que eu acho que é válido: provavelmente não é uma boa idéia aqui, como seria muito útil saber imediatamente quando um ID não existe.

E eu também acho nulo padrão aqui seria o peso um pouco pesado

Comentário de Rob Wells em jogar exceção, pois seu mau Id: eu não acho que um erro de digitação no nome do paciente é uma circunstância excepcional" IMHO

Foi útil?

Solução

Tenha em mente que vai "sobre o fio" para outro nível (se um banco de dados ou um servidor de aplicação) é uma das atividades mais caras que você pode fazer - geralmente uma chamada de rede terá várias ordens de magnitude maior do que in- chamadas de memória.

É, portanto, vale a pena estruturação sua API para evitar chamadas redundantes.

Considere, se sua API é assim: 

// Check to see if a given patient exists
public bool PatientExists(int id);

// Load the specified patient; throws exception if not found
public Patient GetPatient(int id);

Em seguida, é provável que atingiu o banco de dados duas vezes -. Ou ser dependente de boa caching para evitar este

Outra consideração é esta: Em alguns lugares, o código pode ter um "em boas condições" id, em outros lugares não. Cada local requer um diferente política sobre se uma exceção deve ser acionada.

Aqui está um padrão que eu usei com bons resultados no passado - tem dois métodos: 

// Load the specified patient; throws exception if not found
public Patient GetExistingPatient(int id);

// Search for the specified patient; returns null if not found
public Patient FindPatient(int id);

Claramente, GetExistingPatient () pode ser construído chamando FindPatient ().

Isso permite que o código de chamada para obter o comportamento apropriado, lançando uma exceção se alguma coisa tem de errado se foi, e evitando manipulação de exceção nos casos em que não é necessário.

Outras dicas

Outra opção seria a Null objeto padrão .

Você provavelmente deve lançar uma exceção. Se você tem um id que não aponta para um paciente válido, de onde ele vem? Algo muito ruim tem provavelmente aconteceu. É uma circunstância excepcional.

EDIT: Se você está fazendo algo que não seja uma recuperação baseada em número inteiro, como uma pesquisa com base em texto, em seguida, retornar null é bom. Especialmente desde que, nesse caso, você está retornando um conjunto de resultados, que poderia ser mais do que um (mais de um paciente com o mesmo nome, a mesma data de nascimento, ou qualquer que seja seu critério é).

A função de pesquisa deve ter um contrato diferente de uma função de recuperação.

Depende:

Se você considerar o funcionamento normal levará a um número pation que não corresponde um arquivo no DB em seguida, um (NULL) registro vazio deve ser devolvido.

Mas se você espera que um determinado ID deve sempre bateu um recorde, em seguida, quando não é encontrado (que deve ser raro), em seguida, usar uma exceção.

Outras coisas como um erro de conexão DB deve gerar uma exceção.
Como você espera que em situações normais a consulta ao banco de dados para sempre trabalho (embora ele pode retornar 0 registros ou não).

P.S. eu não retornar um ponteiro. (Quem possui o ponteiro ??)
Eu gostaria de voltar um objeto que pode ou não ter o registro. Mas que você pode interogated para a existência do registro dentro. Potencialmente um ponteiro inteligente ou somthing um pouco mais esperto do que um ponteiro inteligente que entende o cotext.

Para esta circunstância, eu teria o nulo de retorno do método para um paciente inexistente.

I tendem a preferir o uso de exceções para ajudar degradação graeful quando há um problema com o sistema em si.

Neste exemplo, é mosdt provavelmente:

  1. um erro na ID do paciente se ele foi celebrado um formulário de pesquisa,
  2. um erro de entrada de dados, ou
  3. uma questão de fluxo de trabalho em que o registro de que ele paciente ainda não foi introduzido.

Por isso, retornando um nulo em vez de uma exceção.

Se havia um problema entrar em contato com o banco de dados, então eu teria o raise método uma exceção.

Editar:. Apenas viu que a identificação do paciente na assinatura era um inteiro, graças Steven Lowe, para que eu tenha corrigido minha lista de motivos

Meu ponto básico sobre delineando quando usar exceções (por erros do sistema) versus outros métodos de retornar um erro (por erros de entrada de dados simples) ainda permanece embora. IMHO.

HTH

aplausos,

Rob

Em uma situação simples como este 1. parece ser mais do que suficiente. Você pode querer implementar algo como um método de retorno de chamada que o cliente chama de saber por que ele retornou nulo. Apenas uma sugestão.

tomar o seu descriptiong pelo valor de face, você provavelmente precisará de ambos:

  • IDs ruins são erros / exceções, como Adam apontou, mas
  • Se você é dado IDs em outros lugares que poderia ter desaparecido, você vai precisar do método de consulta para verificar se eles

Supondo que eu leu corretamente ... Quando você chama Paciente (100) ele irá retornar uma referência de objeto para um paciente com um ID de 100. Se nenhum paciente com um ID de 100 existe, eu acho que ele deve retornar nulo. As exceções são em demasia IMO e este caso não exige isso. A função simplesmente retornou um nulo. Ele não criou alguns casos errored que podem travar o seu aplicativo (a menos, claro, você acabou não manipulação que nula e passou-o a alguma outra parte do seu aplicativo).

Eu definitivamente tem essa função de retorno 'nulo', especialmente se fosse parte de alguma pesquisa, onde um usuário poderia procurar um paciente com um determinado ID e se a referência do objeto acabou sendo nula, seria simplesmente afirmar que nenhum paciente com esse id existe.

lançar uma exceção.

Se você retornar null, um código como este: 

Console.WriteLine(Patient(id).Name);

falharia com um NullReferenceException se o id não existe, que não é tão útil como dizer um PatientNotFoundException (id). Neste exemplo, ainda é relativamente fácil de rastrear, mas considere: 

somePatient = Patient(id)

// much later, in a different function:

Console.WriteLine(somePatient);

Sobre a adição de uma função que verifica se um paciente existe: Nota isso não vai impedir PatientNotFoundExceptions completamente. Por exemplo: 

if (PatientExists(id))
    Console.WriteLine(Patient(id).Name);

- outro segmento ou outro processo poderia excluir o paciente entre as chamadas para PatientExists e paciente. Além disso, isso significaria duas consultas de banco de dados em vez de um. Normalmente, é melhor apenas tentar a chamada, e tratar a exceção.

Note que a situação é diferente para consultas que retornam vários valores, por exemplo, como uma lista; aqui, é apropriado para retornar uma lista vazia se não houver partidas.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top