Verificações de dados em Getter/Setter ou em outro lugar?

Question

Estou me perguntando se é uma boa ideia fazer verificações em getters e levantadores, ou em outro lugar no código.

Isso pode surpreendê-lo quando se trata de otimizações e excesso de velocidade upar o código, acho que você não deve fazer verificações em getters e setters, mas sim no código onde você está atualizando seus arquivos ou banco de dados.Estou errado?

Answer 1

Bem, uma das razões pelas quais as classes geralmente contêm membros privados com getters/setters públicos é exatamente porque eles podem verificar dados.

Se você tiver um número que pode estar entre 1 e 100, eu definitivamente colocaria algo no setter que validasse isso e talvez lançaria uma exceção que está sendo capturada pelo código.A razão é simples:Se você não fizer isso no setter, lembre-se daquela limitação de 1 a 100 toda vez que configurá-lo, o que leva à duplicação do código ou quando você o esquece, leva a um estado inválido.

Quanto ao desempenho, estou com Knuth aqui:

“Devíamos esquecer as pequenas eficiências, digamos, cerca de 97% das vezes:Otimização prematura é a raiz de todo o mal."

Answer 2

@Terrapin, referente a:

Se tudo o que você tem é um monte de propriedades simples de [conjunto público/obtenção] ...Eles também podem ser campos

As propriedades têm outras vantagens sobre os campos.Eles são um contrato mais explícito, são serializados, podem ser depurados posteriormente, são um bom lugar para extensão por meio de herança.A sintaxe mais desajeitada é uma complexidade acidental - o .net 3.5, por exemplo, supera isso.

Uma prática comum (e falha) é começar com campos públicos e transformá-los em propriedades posteriormente, “conforme necessário”.Isso quebra seu contrato com quem consome sua aula, então é melhor começar pelas propriedades.

Answer 3

Depende.

Geralmente, o código deve falhar rapidamente.Se o valor puder ser definido por vários pontos no código e você validar somente após recuperar o valor, o bug parece estar no código que faz a atualização.Se os setters validarem a entrada, você saberá qual código está tentando definir valores inválidos.

Answer 4

Do ponto de vista de ter o código mais sustentável, acho que você deve fazer o máximo de validação possível no setter de uma propriedade.Dessa forma, você não armazenará em cache ou lidará com dados inválidos.

Afinal, é para isso que servem as propriedades.Se tudo que você tem é um monte de propriedades como...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

...eles poderiam muito bem ser campos

Answer 5

Você pode querer dar uma olhada Design baseado em domínio, de Eric Evans.DDD tem esta noção de Especificação:

...Objetos de valor do tipo predicado explícito para fins especializados.Uma especificação é um predicado que determina se um objeto satisfaz ou não alguns critérios.

Acho que falhar rápido é uma coisa, a outra é onde manter a lógica para validação.O domínio é o lugar certo para manter a lógica e acho que um objeto de especificação ou um método de validação em seus objetos de domínio seria um bom lugar.

Answer 6

A validação deve ser capturada separadamente dos getters ou setters em um método de validação.Dessa forma, se a validação precisar ser reutilizada em vários componentes, ela estará disponível.

Quando o setter é chamado, tal serviço de validação deve ser utilizado para limpar a entrada no objeto.Dessa forma, você sabe que todas as informações armazenadas em um objeto são válidas em todos os momentos.

Você não precisa de nenhum tipo de validação para o getter, porque as informações no objeto já são consideradas válidas.

Não salve sua validação até uma atualização do banco de dados!!É melhor falhar rápido.

Answer 7

Eu gosto de implementar IDataErrorInfo e coloquei minha lógica de validação em suas propriedades Error e this[columnName].Dessa forma, se você quiser verificar programaticamente se há um erro, você pode simplesmente testar qualquer uma dessas propriedades no código ou pode entregar a validação para a ligação de dados em Web Forms, Windows Forms ou WPF.

A propriedade Binding "ValidatesOnDataError" do WPF torna isso particularmente fácil.

Answer 8

Tento nunca deixar meus objetos entrarem em um estado inválido, para que os setters definitivamente tenham validação, assim como quaisquer métodos que alterem o estado.Dessa forma, nunca preciso me preocupar se o objeto com o qual estou lidando é inválido.Se você mantiver seus métodos como limites de validação, nunca precisará se preocupar com estruturas de validação e chamadas de método IsValid() espalhadas por todo o lugar.