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

votos
9

Eu estou querendo saber se é uma boa idéia para fazer verificações em getters e setters , ou em outras partes do código.

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

Publicado 05/08/2008 em 20:51
fonte usuário
Em outras línguas...                            


8 respostas

votos
13

Bem, um dos reaons por aulas normalmente contêm membros privados com getters / setters públicos é exatamente porque eles podem verificar os dados.

Se você tem um número que pode estar entre 1 e 100, eu iria colocar algo na setter que valida isso e então talvez lançar uma exceção que está sendo capturado pelo código. A razão é simples: Se você não fazê-lo no setter, você tem que lembrar que 1 a 100 limitação cada vez que você configurá-lo, o que leva a código duplicado ou quando você esquecê-lo, ele leva a um estado inválido.

Quanto ao desempenho, eu sou com Knuth aqui:

"Devemos esquecer sobre pequenas eficiências, digamos cerca de 97% do tempo: otimização prematura é a raiz de todo o mal."

Respondeu 05/08/2008 em 20:59
fonte usuário

votos
4

@Terrapin, RE:

Se tudo que você tem é um bando de [Simples set público / obter] propriedades ... eles poderiam muito bem ser campos

Propriedades têm outras vantagens sobre os campos. Eles são um contrato mais explícito, eles são serializados, eles podem ser depurado depois, eles são um bom lugar para a extensão por meio de herança. A sintaxe clunkier é uma complexidade acidental - Líquido 3,5, por exemplo, ultrapassa este.

Uma prática comum (e falho) é começar com campos públicos, e transformá-los em propriedades posteriormente, numa base 'conforme necessário'. Isso quebra o contrato com qualquer um que consome sua classe, por isso é melhor começar com propriedades.

Respondeu 08/08/2008 em 01:07
fonte usuário

votos
3

Depende.

Geralmente, o código deve falhar rápido. Se o valor pode ser definido por vários pontos do código e você valida somente em depois de recuperar o valor, o erro parece estar no código que faz a atualização. Se os setters validar a entrada, você sabe o código está tentando definir valores inválidos.

Respondeu 05/08/2008 em 20:59
fonte usuário

votos
3

A partir da perspectiva de ter o código mais fácil de manter, eu acho que você deve fazer o máximo de validação que puder no setter de uma propriedade. Desta forma, você não vai ser cache ou de outra forma lidar com dados inválidos.

Afinal, é isso que as propriedades são destinadas para. Se tudo que você tem é um bando de imóveis como ...

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

... eles poderiam muito bem ser campos

Respondeu 05/08/2008 em 20:59
fonte usuário

votos
1

Tento nunca deixar meus objetos de entrar em um estado inválido, então setters definitivamente teria validação, bem como quaisquer métodos que mudam de estado. Desta forma, eu nunca precisa se preocupar que o objeto que eu estou lidando com é inválido. Se você mantiver seus métodos como limites de validação, então você nunca precisa se preocupar com frameworks de validação e chamadas de método IsValid () polvilhadas em todo o lugar.

Respondeu 23/09/2008 em 20:44
fonte usuário

votos
1

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

"ValidatesOnDataError" propriedade de ligação do WPF torna este particularmente fácil.

Respondeu 07/08/2008 em 23:24
fonte usuário

votos
1

Você pode querer verificar Domain Driven Design , por Eric Evans. DDD tem essa noção de uma Especificação:

... explícita valor de predicado-como materiais para fins especializados. A especificação é um predicado que determina se um objeto faz ou não satisfazer alguns critérios.

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

Respondeu 05/08/2008 em 21:03
fonte usuário

votos
1

A validação deve ser capturado separadamente getters ou de formadores em um método de validação. Dessa forma, se a validação precisa ser reutilizado em vários componentes, está disponível.

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

Você não precisa de qualquer tipo de validação para o getter, porque a informação sobre o objeto já é confiável para ser válido.

Não salvar a sua validação até que uma atualização de banco de dados !! É melhor falhar rapidamente .

Respondeu 05/08/2008 em 20:55
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more