É uma boa prática de programação não usar getters e setters em partes triviais do código? [duplicado]

4

É uma boa prática de programação não usar getters e setters em partes triviais do código?

    
por user13806 20.01.2011 / 17:32
fonte

8 respostas

9

Não na minha opinião. (Por que você pensaria o contrário?)

No mínimo, a consistência deve ser um fator importante em uma base de código , então eu teria pensado que se getter / setters forem usados, eles devem ser usados globalmente.

Além disso, o que é trivial agora pode acabar sendo uma grande distância do trivial em seis meses, então seria ingênuo supor o contrário e tratar esses segmentos de código de maneira diferente.

    
por 20.01.2011 / 17:35
fonte
6

É uma boa prática de programação não usar getters e setters em classes que se destinam a ser mais do que pacotes de dados (como um C struct ). Eles expõem a estrutura interna da classe, violando o encapsulamento e aumentando muito o acoplamento. Os métodos públicos devem ser usados para expressar operações significativas de acordo com o que a classe representa, não de acordo com a implementação.

Para classes que são fundamentalmente pacotes de dados, elas são mais complicadas do que simplesmente tornar públicos os dados da classe, mas oferecem um pouco mais de controle. Às vezes, prefiro variáveis públicas porque são mais limpas, mas os setters permitem inserir ganchos nas modificações, o que me poupou muito trabalho uma vez.

    
por 20.01.2011 / 17:58
fonte
4

Uma classe com pares extensos de getter / setter pode ser mal projetada (no sentido de que pode estar impropriamente encapsulando seus detalhes de implementação). Mas os getters / setters em si não costumam ser o problema em tal cenário, o simples fato de que os dados são públicos geralmente é, portanto, em tal cenário, uma grande lista de variáveis públicas pode ser tão ruim quanto isso.

É realmente difícil dizer sem ver exemplos concretos; Eu pessoalmente evito fazer generalizações como a da sua pergunta (favorecendo afirmações mais fracas envolvendo "poder", "poderia ser", "possivelmente", etc.). Se uma classe é destinada a ser uma abstração de nível muito alto, ela provavelmente deve ter menos pares get / set triviais do que algo modelando um conceito de nível inferior.

Se, em particular, você quer dizer que o código "trivial" é um código único específico para testar uma ideia ou programas muito pequenos, provavelmente não há necessidade de reformular ou exagerar a solução.

    
por 20.01.2011 / 17:41
fonte
3

Eu diria que você quer TDD (E com isso quero dizer Test Driven Design ) seus objetos. Você perceberá rapidamente se realmente precisa desses setters e getters. Eu, pessoalmente, apenas escrevo o código que preciso.

Ah, e se seu design mais tarde disser que eu preciso de todos esses getters e setters, então é para isso que os IDEs modernos são:)

    
por 20.01.2011 / 17:59
fonte
3

Nenhum código é trivial

Se, em tempo de execução, a CPU a executa, ela não é trivial porque está tendo efeito.

É tudo sobre encapsulamento

Se você quiser violar praticamente todos os conselhos sobre o encapsulamento de dados no livro OOP, exponha o estado interno do seu objeto a todos. Simplesmente torne o campo público e você sairá. Em pouco tempo, todas as referências que você está distribuindo serão modificadas por alguma chamada distante de uma chamada de uma chamada e seu objeto não é o mais sábio - até que venha a executar alguma operação que resulte em falha épica.

Falha épica? Eu não quero isso ...

Se você quiser ter certeza de que apenas seu objeto está mudando, seu próprio estado interno, então getters / setters é o caminho a ser seguido. O getter / setter protege o estado interno, certificando-se de que as classes externas não têm outra maneira de obtê-lo. (OK, eu ouço sua subclassificação, reflexão yada yada ...)

Tem um exemplo para conquistar isso?

Considere a exposição de matrizes. Se você fizer isso diretamente através de um getter, como este (em Java)

public byte[] getRedBackgroundPDF() {
  return this.redPDF;
}

você obtém uma falha épica porque o byte[] é passado por referência e, portanto, as classes externas podem modificar as partes internas de sua classe, evitando a finalidade do getter. O PDF pode ser modificado de alguma maneira (digamos, para ter um plano de fundo azul) e sua turma não faz ideia.

Para superar isso, você precisa clonar para que as classes externas obtenham efetivamente uma versão somente leitura do byte[] .

public byte[] getRedBackgroundPDF() {
  return Arrays.copyOf(this.redPDF,this.redPDF.length) ;
}

O código externo pode alterar isso para azul, mas toda vez que alguém visitar o método getRedBackgroundPDF() , ele sempre começará com um plano de fundo vermelho.

Parece desnecessário e feio, mas protege o seu estado interno.

    
por 20.01.2011 / 18:32
fonte
1

De acordo com Jon Skeet (do StackOverflow fame) -

What is a trivial property ? It's one that’s read/write and that stores its value in a straightforward private variable without any validation or other custom code. Trivial properties only take a few lines of code, but it’s still a lot when you consider that you’re only expressing a very simple concept.

Where previously you might have been tempted to use a public variable for the sake of simplicity, there’s now even less excuse for not using a property instead. This is particularly true for throwaway code—which we all know tends to live far longer than anticipated.

EDIT - Eu recomendaria usar para usar propriedades automáticas sempre que possível. Para mim, permite-me saber em uma única olhada que esta propriedade não está fazendo nada extravagante. Também torna o código mais legível.

    
por 20.01.2011 / 18:18
fonte
0

A noção de getters e setters é um extremismo totalmente estúpido, então você não deve usá-los. Aqui está o porquê:

Se você tiver um tipo de produto, como uma estrutura em C, receberá as projeções categóricas (getters) como parte do idioma e deverá usá-las. Em C eles também são úteis para definir um valor e também operações de leitura / modificação / gravação. Os produtos são tipos de dados concretos, não há nada abstrato sobre eles e seus dados devem ser públicos. Algumas linguagens idiotas ocultam dados por padrão ou permitem a leitura, mas não a escrita.

As abstrações devem ser evitadas a todo custo. A abstração é dispendiosa computacionalmente, e não me refiro ao computador (embora geralmente seja esse o caso): quero dizer, para o cérebro humano. Basta olhar para todo o lixo ridículo em linguagens OO em comparação com a codificação simples em uma linguagem funcional: até mesmo linguagens pobres como o C podem ser muito expressivas.

A abstração é útil quando você tem invariantes e tem certeza deles e gostaria de aplicá-los. Nesse caso, tipicamente os construtores estabelecem a invariante, os dados são ocultados para impedir o uso das projeções para quebrar a invariante e, em seguida, você precisa de acessadores para obter informações sobre o valor do objeto.

Se o objeto é mutável, claramente você precisa modificá-lo.

No entanto, eles não são "getters e setters" no sentido de configurar componentes de um tipo de produto, porque é isso que você está tentando evitar, pois alguns valores da estrutura de dados privada não representam valores do tipo abstrato.

    
por 22.01.2011 / 16:11
fonte
-1

Sim. Eu não uso get / set para atributos privados se eles não são usados fora da classe e a classe não pode ser herdada.

Se você precisar acessar o atributo fora da classe, um get / set está em ordem. Um get sem set para uma classe imutável, um get / set para mutável.

Quando eu preciso de um monte desses, eu pego meu IDE e deixo gerá-los para mim.

    
por 20.01.2011 / 18:05
fonte