Modificando argumento setter - é Hack ou não?

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

  •  10-07-2019
  •  | 
  •  

Pergunta

É normal para modificar argumentos setter? Vamos imaginar que temos método setString. E nós realmente queremos manter uma forma recortada da cadeia. Então, uma string com espaços à direita é inválido, mas não queremos lançar uma exceção.

Qual é a melhor solução? Para aparar o valor no setter por exemplo. 

public void setString(String string) {
    this.string = string.trim();
}

Ou cortá-la no chamador (mais de uma vez) por exemplo. 

object.setString(string.trim());

Ou talvez algo mais?

Foi útil?

Solução

Sim. Afinal, setters são projetados para este tipo de coisas! Para controlar e higienizar os valores escritos para campos;)

Outras dicas

Totalmente. Aqui está um exemplo: suponha que você tenha um programas de engenharia com diferentes tipos de unidades de medida. Você mantém os valores internos de um sistema de medição, mas você converter de todos os outros no setter, e converter de volta no getter, por exemplo:. 

public double UserTemperature
{
  get
  {
    return Units.Instance.ConvertFromSystem(UnitType.Temperature, temperature);
  }
  set  
  {
    double v = Units.Instance.ConvertToSystem(UnitType.Temperature, value);
    if (temperature != v)
    {
      temperature = v;
      Changed("SystemTemperature");
      Changed("UserTemperature");
    }
  }
}

Sim, com certeza. Basta ter cuidado para verificar NULL antes de aplicar qualquer método (como guarnição ()).

Há duas escolas: uma diz que seu ok para verificar param em setter (escola estilo) e, segundo se diz feijão não deve conter qualquer lógica e os dados apenas (estilo empresa)

.

Eu acredito mais na segunda. Quantas vezes você olhar para implementação de seus feijões? Should getUser lançar qualquer exceção ou apenas return null?

Quando você colocar lógica em seu setter e getters você faz mais difícil de entender o que está acontecendo uma vez que muitas pessoas nunca vão olhar para a sua implementação. Se você não concordar Exorto-vos a olhar para cada setter e getter implementação antes de usá-lo apenas para verificar se a sua não apenas um feijão.

À primeira vista parece que viola o princípio de menos espanto . Se eu sou um usuário de sua classe, eu esperaria um setter para fazer exatamente o que eu diga a ele. Eu lançar uma exceção no setter para forçar os usuários a cortar a entrada.

O outro (melhor?) Alternativa é mudar o nome do método para trimAndSetString. Dessa forma, não é um comportamento surpreendente para cortar a entrada.

me corrija se eu estiver errado, mas parece-me lógico que o setter deve manter esse tipo de lógica. Se o setter é apenas atribuir algum valor a um var interna sem verificá-lo, então por que não expor a própria var?

Este é exatamente por isso que você usa setters em vez de expor os campos objetos para o mundo inteiro.

Considere uma classe que contém um ângulo inteiro que é esperado para estar entre 0 e 359, inclusive.

Se você expor o campo, as funções de chamada pode configurá-lo para o que eles querem e isso iria quebrar o contrato especificado pelo seu API. É também provável que quebrar a sua funcionalidade em algum lugar abaixo da pista porque seu código é escrito para assumir um determinado intervalo para essa variável.

Com um setter, há uma série de coisas que você pode fazer. Um deles é para levantar uma exceção para indicar um valor inválido foi passado, mas que seria incorreto, na minha opinião (para este caso). É provável que seja mais útil se você modificar o valor de entrada para algo entre 0 e 359, como com: 

actualVal = passedValue % 360;

Enquanto isso é especificado na sua interface (API), é perfeitamente válido. Na verdade, mesmo se você não especificá-lo, você ainda está livre para fazer o que quiser desde que o chamador tenha violado o contrato (passando um valor fora do intervalo). I tendem a seguir a regra de "higienizar sua entrada mais cedo possível".

No seu caso específico, contanto que você especificar que a string é armazenado em formato aparado, não há nenhuma razão para os chamadores para reclamar (que você já tenha afirmado que tal seqüência de um é inválido). É melhor em termos de tamanho de código (não velocidade) para fazê-lo no setter, em vez de em cada pedaço de código que chama o setter. Ele também garante que a seqüência é armazenado como você espera que ele seja -. Não há garantia de um chamador não acidentalmente (ou intencionalmente) armazenar uma string não-aparadas

Sim. É uma característica de projeto orientado a objetos é que o chamador pode tratar a sua classe como uma caixa preta. O que você faz dentro é o seu próprio negócio, enquanto o comportamento da interface está documentada e lógica.

Enquanto as pessoas diferentes têm filosofias diferentes, gostaria de sugerir que os setters de propriedade só são adequadas em casos onde vai estabelecer um aspecto do estado do objeto para coincidir com o valor indicado e, talvez, possivelmente notificar qualquer pessoa que se preocupa com a mudança, mas não vai de outra forma afetar o estado do objeto (que é perfeitamente adequada para uma propriedade setter para alterar o valor de um read-only propriedade se essa propriedade é definida em termos de estado associado ao setter propriedade, por exemplo, propriedade Right somente leitura de um controle pode ser definido em termos de sua Bounds). setters de propriedade deve lançar uma exceção se eles não podem executar a operação indicada.

Se alguém deseja permitir que um cliente para modificar o estado de um objeto de alguma forma não cumprir a descrição acima, deve-se usar um método, em vez de uma propriedade. Se um chamadas Foo.SetAngle(500) seria de se esperar razoavelmente que o método usará o parâmetro indicado na definição do ângulo, mas a propriedade Angle pode não retornar o ângulo da mesma forma como foi definido (por exemplo, ele pode retornar 140). Por outro lado, se Angle é uma propriedade de leitura e escrita, seria de esperar que escrever um valor de 500 ou seria proibido ou então faria com que o valor de ler de volta 500. Se um queria ter o objeto armazenar um ângulo na intervalo de 0 a 359, o objeto também poderia ter uma propriedade somente leitura chamada BaseAngle que sempre retornará um ângulo em que forma.

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