Por que seguir get-set e não car.speed() e car.speed(55) respectivamente?

Question

Além da clareza inequívoca, por que deveríamos nos ater a:
car.getSpeed() e car.setSpeed(55)
quando isso também pode ser usado:car.speed() e car.speed(55)

Eu sei que get() e set() são úteis para manter qualquer alteração no membro de dados gerenciável, mantendo tudo em um só lugar.

Além disso, obviamente, eu entendo que car.speed() e car.speed(55) são as mesmo function, o que torna isso errado, mas no PHP e também no Zend Framework, a mesma ação é usada para GET, POST, postbacks.
Em VB e C# existem "propriedades" e são usadas por muitos, para desgosto dos puristas que ouvi, e há coisas em Ruby como 5.times e .each, .to_i etc.
E você tem sobrecarga de operador, herança múltipla, funções virtuais em C++, certas combinações das quais podem deixar qualquer um maluco.

Quero dizer que existem tantos paradigmas e formas de fazer as coisas que parece estranho que ninguém tenha tentado a combinação específica que mencionei.

Quanto a mim, a minha razão é que é curto e mais limpo de ler o código.
Estou muito errado, um pouco errado, isso é estranho e não é usado, ou o que mais?

Se eu ainda decidir permanecer correto, eu poderia usar car.speed() e car.setSpeed(55).
Isso está errado de alguma forma (apenas omitindo o "get" )?

Obrigado por qualquer explicação.

Answer 1

Se eu chamasse car.speed(), poderia pensar que estou dizendo ao carro para acelerar, em outras palavras, para aumentar a velocidade e ultrapassar o limite de velocidade.Não é claramente um getter.

Algumas linguagens permitem declarar objetos const e, em seguida, restringem você a chamar apenas funções que não modificam os dados do objeto.Portanto, é necessário ter funções separadas para operações de modificação e leitura.Embora você possa usar sobrecargas em parâmetros para ter duas funções, acho que seria confuso.

Além disso, quando você diz que é mais claro de ler, posso argumentar que preciso olhar adiante para entender como lê-lo:

car.speed()

Eu li "velocidade do carro..." e então vejo que não há número, então reviso e penso "obter velocidade do carro".

car.getSpeed()

Eu li "para este carro, ganhe velocidade"

car.setSpeed(55)

Eu li "para este carro, ajuste a velocidade para 55"

Parece que você basicamente citou outros recursos da linguagem como confusos e depois usou isso como uma defesa para tornar os getters/setters mais confusos.Quase parece que estamos admitindo que o que você propôs é mais confuso.Esses recursos às vezes são confusos devido ao seu propósito geral.Às vezes, as abstrações podem ser mais confusas, mas no final muitas vezes servem ao propósito de serem mais reutilizáveis.Acho que se você quisesse argumentar a favor de speed() e speed(55), gostaria de mostrar como isso pode permitir novas possibilidades para o programador.

Por outro lado, C# tem algo parecido com o que você descreve, já que as propriedades se comportam de maneira diferente como getter ou setter dependendo do contexto em que são usadas:

Console.WriteLine(car.Speed); //getter

car.Speed = 55 //setter

Mas embora seja uma propriedade única, há duas seções separadas de código para implementar a obtenção e a configuração, e está claro que este é um getter/setter e não uma velocidade de função, porque eles omitem () para propriedades.Então car.speed() é claramente uma função, e car.speed é claramente um getter de propriedade.

Answer 2

IMHO, o estilo C# de ter propriedades como açúcar sintático para métodos get e set é o mais expressivo.

Answer 3

Eu prefiro objetos ativos que encapsulam operações em vez de getters e setters, para que você obtenha objetos semanticamente mais ricos.

Por exemplo, embora seja um ADT e não um objeto de negócio, mesmo o vector em C++ tem funções emparelhadas:

size_type capacity() const // how many elements space is reserved for in the vector  
void reserve(size_type n)  // ensure space is reserved for at least n elements 

e

void push_back ( const T& ) // inserts an element at the end
size_type size () const     // the number of elements in the vector

Se você dirige um carro, pode definir o acelerador, a embreagem, os freios e a seleção de marcha, mas não define a velocidade.Você pode ler a velocidade no velocímetro.É relativamente raro querer um setter e um getter em um objeto com comportamento.

Answer 4

Para sua informação, usos do Objective-C car.speed() e car.setSpeed(55) (exceto em uma sintaxe diferente, [car speed] e [car setSpeed:55].

É tudo uma questão de convenção.

Answer 5

Não existe uma resposta certa, é uma questão de estilo e, em última análise, não importa.Gaste seus ciclos cerebrais em outro lugar.

FWIW eu prefiro o classe.substantivo() para o getter, e classe.verbo() para o levantador.Às vezes o verbo é apenas setNoun(), mas outras vezes não.Depende do substantivo.Por exemplo:

my_vector.size() 

retorna o tamanho e

my_vector.resize(some_size) 

muda o tamanho.

Answer 6

A abordagem bacana das propriedades é excelente, IMHO, http://groovy.codehaus.org/Groovy+Beans

Answer 7

Os benchmarks finais do seu código devem ser estes:

1. Funciona corretamente?
2. É fácil consertar se quebrar?
3. É fácil adicionar novos recursos no futuro?
4. É fácil para alguém entrar e consertar/melhorar isso?

Se esses 4 pontos forem cobertos, não consigo imaginar por que alguém teria problemas com isso.A maioria das “Melhores Práticas” geralmente são voltadas para atingir esses 4 pontos.

Use o estilo que funcionar para você, apenas seja consistente e você ficará bem.

Answer 8

Isto é apenas uma questão de convenção.No Smalltalk, é feito da maneira que você sugere e não me lembro de ter ouvido alguém reclamar disso.Obter a velocidade do carro é car speed, e definir a velocidade do carro para 55 é car speed:55.

Se eu arriscasse um palpite, diria que a razão pela qual esse estilo não pegou é por causa das duas linhas abaixo nas quais a programação orientada a objetos chegou até nós:C++ e Objective-C.Em C++ (ainda mais no início de sua história), os métodos estão intimamente relacionados às funções C, e as funções C são convencionalmente nomeadas de acordo com as linhas de setWhatever() e não possuem sobrecarga para diferentes números de argumentos, de modo que o estilo geral de nomenclatura foi mantido.Objective-C foi amplamente preservado pela NeXT (que mais tarde se tornou Apple), e a NeXT tendia a favorecer a verbosidade em suas APIs e especialmente a distinguir entre diferentes tipos de métodos - se você estiver fazendo qualquer coisa, mas apenas acessando uma propriedade, a NeXT queria um verbo Para deixar claro.Então essa se tornou a convenção no Cocoa, que é a biblioteca padrão de fato para Objective-C atualmente.

Answer 9

É convenção Java tem uma convenção de getters e setters C# tem propriedades, python tem campos públicos e estruturas JavaScript tendem a usar field() para obter e field(value) para definir

Answer 10

Além da clareza inequívoca, por que deveríamos nos ater a:Car.getSpeed ​​() e Car.SetSpeed ​​(55) quando isso também pode ser usado:car.speed() e car.speed(55)

Porque em todos os idiomas que encontrei, car.speed() e car.speed(55) são iguais em termos de sintaxe.Só de olhar para eles assim, ambos poderiam retornar um valor, o que não é verdade para o último se fosse para ser um levantador.

Answer 11

E se você pretende ligar para o levantador, mas se esquece de argumentar?O código é válido, portanto o compilador não reclama e não gera um erro imediato de tempo de execução;é um bug silencioso.

Answer 12

.() significa que é um verbo.não () significa que é um substantivo.

   car.Speed = 50;
   x = car.Speed
   car.Speed.set(30)
   car.setProperty("Speed",30)

mas

   car.Speed()

implica comando para exceder o limite de velocidade.