¿Por qué se adhieren a get-set y no a car.speed() y car.speed (55) respectivamente?

Question

Además de la claridad inequívoca, ¿por qué se adhieren a:
car.getSpeed() y car.setSpeed(55)
cuando esto podría ser utilizado, así: car.speed() y car.speed(55)

Sé que get() y set() son útiles para mantener cualquier cambio en el miembro de datos puede gestionarse manteniendo todo en un solo lugar.

También, obviamente, entiendo que car.speed() y car.speed(55) son la misma función , lo que hace que este mal, pero luego en PHP y también en Zend Framework, la misma acción se utiliza para GET, POST, las devoluciones de datos.
En VB y C# hay "propiedades", y son utilizados por muchos, para gran disgusto de los puristas que he oído, y hay cosas en Ruby como 5.times y .each, etc. .to_i
Y usted tiene la sobrecarga de operadores , herencia múltiple, funciones virtuales en C++, ciertas combinaciones de las cuales podrían volver loco a cualquiera.

Quiero decir que hay tantos paradigmas y formas en que se hacen las cosas que parece extraño que nadie haya probado la combinación particular que mencioné.

En cuanto a mí, mi razón es que es corto y más limpio para leer el código.
¿Estoy muy equivocado, ligeramente equivocado, esto es simplemente extraño y por lo tanto no utilizado, o qué más?

Si todavía decido mantenerme en forma, podría usar car.speed() y car.setSpeed(55).
¿Está mal de alguna manera (simplemente omitiendo el "obtener")?

Gracias por cualquier explicación.

Answer 1

Si llamé a car.speed(), podría pensar que le estoy diciendo al automóvil que acelere, en otras palabras para aumentar la velocidad y romper el límite de velocidad. No es claramente un getter.

Algunos idiomas le permiten declarar objetos const, y luego restringirlo a funciones de llamada que no modifican los datos del objeto. Por lo tanto, es necesario tener funciones separadas para las operaciones de modificación y lectura. Si bien podrías usar sobrecargas en los parámetros para tener dos funciones, creo que sería confuso.

Además, cuando usted dice que es más claro para leer, puedo afirmar que tengo que hacer una mirada hacia el futuro para entender cómo leerlo:

car.speed() 

leí "la velocidad del coche ..." y entonces veo que no hay número, así que lo reviso y pienso "obtener la velocidad del auto".

car.getSpeed() 

leí "para este coche, conseguir una velocidad"

car.setSpeed(55) 

leí "para este coche, ajustar la velocidad a 55"

Parece básicamente usted ha citado otras características de la el lenguaje por ser confuso, y luego lo usó como defensa para hacer que los getters/setters fueran más confusos? Casi suena como si admitieran que lo que han propuesto es más confuso. Estas características a veces son confusas debido a su propósito general. A veces las abstracciones pueden ser más confusas, pero al final a menudo sirven para ser más reutilizables. Creo que si quisieras argumentar a favor de la velocidad() y la velocidad (55), querrías mostrar cómo eso puede habilitar nuevas posibilidades para el programador.

Por otra parte, C# tiene algo así como lo que describes, ya que las propiedades se comportan de manera diferente como captador o colocador en función del contexto en lo que se utilizan:

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

car.Speed = 55 //setter 

Pero aunque es una sola propiedad, hay dos secciones separadas de código para implementar get y setting, y está claro que esto es un getter/setter y no una velocidad de función, porque omiten el() para las propiedades. Entonces, car.speed() es claramente una función, y car.speed es claramente un captador de propiedades.

Answer 2

En mi humilde opinión el estilo C# de tener propiedades como el azúcar sintético para obtener y establecer los métodos es el más expresivo.

Answer 3

FYI, Objective-C utiliza car.speed() y car.setSpeed(55) (excepto en una sintaxis diferente, [car speed] y [car setSpeed:55].

Todo es cuestión de convención.

Answer 4

El enfoque maravilloso de propiedades es bastante excelente en mi humilde opinión, http://groovy.codehaus.org/Groovy+Beans

Answer 5

Además de claridad inequívoca, ¿por qué deberíamos seguir: car.getSpeed ​​() y car.setSpeed ​​(55) cuando esto podría usarse como w ell: car.speed() y car.speed (55)

Debido a que en todos los idiomas que he encontrado, y car.speed()car.speed(55) son los mismos en términos de sintaxis. Solo mirándolos así, ambos podrían devolver un valor, lo que no es cierto para el último si se suponía que fuera un setter.

Answer 6

Los puntos de referencia final de su código debe ser la siguiente:

1. ¿Funciona correctamente?
2. ¿Es fácil de arreglar si se rompe?
3. ¿Es fácil agregar nuevas funciones en el futuro?
4. ¿Es fácil para otra persona entrar y arreglarlo/mejorarlo?

Si esos 4 puntos están cubiertos, no puedo imaginar por qué alguien tendría un problema con él. La mayoría de las "mejores prácticas" generalmente están orientadas a lograr esos 4 puntos.

Use el estilo que mejor funcione para usted, solo sea consecuente al respecto, y debería estar bien.

Answer 7

Esto es solo una cuestión de convención. En Smalltalk, se hace de la manera que sugieres y no recuerdo haber escuchado nunca a nadie quejarse de ello. Obtener la velocidad del automóvil es car speed, y establecer la velocidad del automóvil en 55 es car speed:55.

Si tuviera que aventurar una suposición, diría que el motivo por el que este estilo no se entendió se debe a las dos líneas en las que nos han llegado las programaciones orientadas a objetos: C++ y Objective-C. En C++ (incluso más temprano en su historia), los métodos están estrechamente relacionados con las funciones C, y las funciones C se nombran convencionalmente según las líneas setWhatever() y no tienen sobrecarga para diferentes números de argumentos, por lo que el estilo general de denominación era mantenido. Objective-C fue preservado en gran parte por NeXT (que luego se convirtió en Apple), y NeXT tendió a favorecer la verbosidad en sus API y especialmente a distinguir entre diferentes tipos de métodos: si está haciendo algo más que simplemente acceder a una propiedad, NeXT quería un verbo Para hacerlo claro. Así que eso se convirtió en la convención en Cocoa, que es la biblioteca estándar de facto para Objective-C en estos días.

Answer 8

Prefiero los objetos activos que encapsulan operaciones en lugar de getters y setters, por lo que obtienes objetos semánticamente más ricos.

Por ejemplo, las funciones a pesar de un TAD en lugar de un objeto de negocio, incluso el vector en C++ ha emparejado:

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 

y

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

Si usted conduce un coche, se puede establecer el selección de acelerador, embrague, frenos y engranaje, pero no establece la velocidad. Puedes leer la velocidad del velocímetro. Es relativamente raro querer tanto un setter como un getter en un objeto con comportamiento.

Answer 9

convención de Java, donde se presenta una convención de captadores y definidores C# tiene propiedades, pitón tiene campos públicas y marcos de JavaScript tienden a utilizar el campo() para obtener y de campo (valor) para establecer

Answer 10

No hay una respuesta correcta, es una cuestión de estilo, y en última instancia, no importa. Gasta tus ciclos cerebrales en otro lado.

Fwiw prefiero la class.noun() para el comprador, y class.verb() para el organismo. Algunas veces el verbo es solo setNoun(), pero otras veces no. Depende del sustantivo. Por ejemplo:

my_vector.size() 

devuelve el tamaño, y

my_vector.resize(some_size) 

cambia el tamaño.

Answer 11

¿Qué sucede si tiene la intención de llamar al colocador pero se le olvida poner el argumento? El código es válido, por lo que el compilador no se queja y no arroja un error de tiempo de ejecución inmediato; es un error silencioso

Answer 12

.() Significa que es un verbo. no() significa que es un sustantivo.

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

pero

car.Speed() 

implica comando para superar el límite de velocidad.