Qual é a vantagem de nomear explicitamente getters e setters como “get ...” e “set ...”?

Question

Será que este irritar alguém lá fora? Eu prefiro muito mais ver:

 block.key(newKey);  // set the key for this block

e

 testKey = block.key();  // look up the key for this block

de

 block.setKey(newKey); // set the key for this block
 testKey = block.getKey(); // look up the key for this block

Em primeiro lugar, o "set" e "pegar" são redundantes (e, portanto, adicionar ruído reduzindo a legibilidade). A ação (set / get) é definida pela sintaxe de cada instrução. Eu entendo a sobrecarga. De fato, usando o mesmo identificador exata reforça que estes são a mesma propriedade do objeto. Quando eu li "getKey ()" e "setKey ()" Eu não pode ter tanta certeza.

Em segundo lugar, se "get" e "set" devem ser estritamente interpretadas como setter e getter, em seguida, se outra semântica associada a definição / obtenção de um valor, efeitos colaterais, por exemplo, será surpreendente.

Eu suponho que esta tendência vem de minha formação Smalltalk, mas em um mundo onde o polimorfismo funciona muito bem, não seria melhor sem o "get" e "set" polvilhado em toda parte? Basta pensar quanto mais código que poderia tipo se não tem que digitar essas três letras repetidas vezes ?! (Língua um pouco na bochecha)

Qualquer um lá fora se sente da mesma maneira?

Answer 1

Prefixando acessores com "get" e mutators com "set" é uma prática que varia de língua para língua, e parece ser principalmente prevalente em Java. Por exemplo:

• Em Python, você tem o conceito de propriedades, e assim por um assessor pode parecer obj.foo e um modificador pode parecer obj.foo = bar (mesmo que métodos são chamados nos bastidores). existem conceitos similares em linguagens como Ruby. Assim, em muitas línguas, as chamadas para os assessores e modificadores olhar como "chamadas" diretos variáveis ??de instância, e você nunca ver qualquer coisa como "setFoo" ou "getFoo".
• Linguagens como Objective-C desencorajar a prática de prefixo acessores com "get", portanto, em Objective-C que você veria chamadas como [obj foo] e [obj setFoo:bar].

Eu nunca gostei da prática de prefixo acessores em Java com "get", qualquer um, mas eu vejo o mérito em prefixar mutators com "set". Dito isto, uma vez que a prática prevalecente é a de prefixo com "get" / "set" em Java, eu continuar a tendência no meu próprio código.

Answer 2

Os projetistas do C #, aparentemente concordamos, e dos C # 'tag supera a língua ao lado mais popular, de 2: 1 em StackOverflow. Então, eu suspeito que você está pregando para o coro.

Answer 3

Várias linguagens têm diferentes maneiras de lidar com getters e setters. Em Java você tem getName e setName, em Qt você tem nome e setName. Eu prefiro o caminho Java por estas razões:

1. E se você tem uma função que é chamada de unidade? Será que isso causa a sua classe a unidade, ou não set / get uma unidade?
2. Com sugestões ligado, você pode digitar começar, e, em seguida, obter todos os getters. Isto é muito útil se você não se lembra o nome de um getter que você precisa.
3. Com base na razão um, ele separa as funções em diferentes grupos. Você tem as funções que fazem algo, eles não começar com obter ou definir (embora talvez eles deveriam começar com tarefas?). Então você tem as funções que obter uma propriedade, e todos eles começam com get. Então você tem as funções que definem uma propriedade, e todos eles começam com set.

Answer 4

Para mim, get e set prefixos fazer meu cérebro fazer o trabalho menos ao ler o código. Quando usado de forma consistente, os métodos get / set torná-lo mais fácil de grep um cabeçalho, possivelmente fazendo a classe mais fácil de aprender e usar. Eu passo desproporcionalmente grande quantidade de tempo de leitura de código de código versus escrita, então os personagens extras para get e set estão bem por mim.

Answer 5

A linguagem Java atualmente não tem propriedades, de modo a sintaxe getter / setter tornou-se o padrão de fato. Se o seu código Java escrito, você estará bem servido para usar a convenção Java. Este não é apenas para que outros programadores podem ler o código, mas o mais importante centenas de outros frameworks Java são construídos para manipular objetos apoiando Java bean getters estilo / setters.

Por exemplo, no Velocity motor de templates , você poderia escrever algo como:

The answer is $block.key

O código acima irá tentar invocar:

block.getkey();
block.getKey();

Se você definiu block.getKey (), então tudo vai funcionar bem. Geralmente é melhor para seguir as convenções da linguagem.

Answer 6

Em nomes gerais da propriedade devem ser substantivos, enquanto nomes de métodos deve ser verbos, portanto, a propriedade no exemplo acima seria chamado de 'driver' eo método seria 'drive'. Não será, evidentemente, casos em que há sobreposição mas em geral isso funciona e torna o código mais legível.

Answer 7

Em C ++ eu só uso sobrecarga

int parameter() const { return m_param }
void parameter(int param) { m_param = param; }

Answer 8

Sim, o get / set em java é essencialmente uma solução de um problema na língua.

Comparando-a com c # properites

http://www.csharp-station.com/Tutorials/Lesson10.aspx

Ou python http: //blog.fedecarg .com / 2008/08/17 / não-necessidade de-setget-methods-em-python /

Eu acho que esta é uma das maiores falhas do java.

Answer 9

C # getters e setters são entidades "primeira classe" e não se parecem com as chamadas de função sintática (embora qualquer código arbitrário pode ser executado no contexto de um sistema de acesso).

Eu só uso get / set em idiomas que me forçar a, como Objective-C.

Answer 10

Você pode facilmente pesquisar sua base de código para referências a getDrive() ou setDrive(). Se o seu método é apenas chamado 'drive', você vai ter muitos mais falsos positivos na busca.

Answer 11

Ouça, ouça.

Eu realmente gosto de notação especial para getters e setters. CLU fez isso melhor:

• Usando p.x numa expressão foi equivalente ao get_x(p) chamada.

• Usando p.x := e (atribuição) foi equivalente ao set_x(p, e) chamada.

Se a interface para o objeto p não exportou get_x ou set_x, você foi impedido de fazer a operação correspondente. Simples.

Vamos ouvi-lo para açúcar sintático!