Pourquoi s'en tenir à get-set et non à car.speed() et car.speed(55) respectivement ?

Question

Au-delà d’une clarté sans ambiguïté, pourquoi devrions-nous nous en tenir à :
car.getSpeed() et car.setSpeed(55)
quand cela pourrait également être utilisé :car.speed() et car.speed(55)

Je sais que get() et set() sont utiles pour que toutes les modifications apportées au membre de données soient gérables en gardant tout au même endroit.

Et évidemment, je comprends que car.speed() et car.speed(55) sont les même fonction, ce qui rend cela faux, mais en PHP et aussi dans Zend Framework, la même action est utilisée pour GET, POST, les publications.
En VB et C#, il y a des "propriétés" et sont utilisées par beaucoup, au grand dégoût des puristes que j'ai entendu, et il y a des choses en Ruby comme 5.times et .each, .to_i etc.
Et vous avez une surcharge d'opérateurs, un héritage multiple, des fonctions virtuelles en C++, dont certaines combinaisons pourraient rendre n'importe qui fou.

Je veux dire qu’il existe tellement de paradigmes et de manières de faire les choses qu’il semble étrange que personne n’ait essayé la combinaison particulière que j’ai mentionnée.

Quant à moi, ma raison est que c'est court et plus propre à lire le code.
Ai-je vraiment tort, légèrement tort, est-ce juste étrange et donc non utilisé, ou quoi d'autre ?

Si je décide quand même de rester correct, je pourrais utiliser car.speed() et car.setSpeed(55).
Est-ce faux (en omettant simplement le "get" ) ?

Merci pour toutes explications.

Answer 1

Si j'ai appelé car.speed (), je pourrais penser que je dis la voiture à la vitesse, autrement dit d'augmenter la vitesse et de briser la limite de vitesse. Il est pas clairement un getter.

Certaines langues vous permettent de déclarer des objets const, puis vous limiter à seulement appeler des fonctions qui ne modifient pas les données de l'objet. Il est donc nécessaire d'avoir des fonctions séparées pour la modification et les opérations de lecture. Alors que vous pouvez utiliser sur paramaters pour les surcharges deux fonctions, je pense que ce serait source de confusion.

En outre, quand vous dites qu'il est plus clair à lire, je peux dire que je dois faire un coup d'œil avant de comprendre comment le lire:

car.speed()

Je lis « vitesse de la voiture ... » et je vois qu'il n'y a pas le numéro, donc je pense que révisent et « obtenir la vitesse de la voiture ».

car.getSpeed()

Je lis "pour cette voiture, obtenir la vitesse"

car.setSpeed(55)

Je lis "pour cette voiture, vitesse réglée à 55"

Il semble que vous avez essentiellement cité d'autres caractéristiques de la langue comme étant source de confusion, puis utilisé que comme un moyen de défense pour faire getters / setters plus confus? On dirait presque admettez que ce que vous avez proposé est plus confuse. Ces caractéristiques sont parfois source de confusion en raison de la façon dont ils sont à usage général. Parfois, les abstractions peuvent être plus déroutant, mais à la fin ils servent souvent dans le but d'être plus réutilisable. Je pense que si vous vouliez plaider en faveur de la vitesse () et la vitesse (55), vous voulez montrer comment cela peut permettre de nouvelles possibilités pour le programmeur.

D'autre part, C # a quelque chose comme ce que vous décrivez, puisque les propriétés se comportent différemment en tant que getter ou setter en fonction du contexte dans ce qu'ils sont utilisés:

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

car.Speed = 55 //setter

Mais alors qu'il est une propriété unique, il y a deux sections séparées de code pour la mise en œuvre du faire et le réglage, et il est clair que c'est un getter / setter et non une vitesse de fonction, car ils omettent le () pour les propriétés . Alors car.speed () est clairement une fonction, et car.speed est clairement un getter de la propriété.

Answer 2

IMHO le style C # d'avoir des propriétés que le sucre syntaxique pour méthodes get et set est le plus expressif.

Answer 3

Je préfère les objets actifs qui encapsulent les opérations plutôt que des accesseurs, de sorte que vous obtenez un des objets sémantiquement riches.

Par exemple, bien qu'un ADT plutôt qu'un objet métier, même le vector en C ++ a des fonctions paire:

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 

et

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

Si vous conduisez une voiture, vous pouvez régler l'accélérateur, l'embrayage, les freins et la sélection des vitesses, mais vous ne réglez pas la vitesse. Vous pouvez lire la vitesse de l'indicateur de vitesse. Il est relativement rare de vouloir à la fois un setter et un getter sur un objet avec le comportement.

Answer 4

FYI, Objective-C utilise car.speed() et car.setSpeed(55) (sauf dans une syntaxe différente, [car speed] et [car setSpeed:55].

Il est tout au sujet de la convention.

Answer 5

Il n'y a pas de bonne réponse, il est une question de style, et, finalement, il n'a pas d'importance. Passez vos cycles du cerveau ailleurs.

FWIW je préfère le class.noun () pour le getter, et class.verb () pour le poseur. Parfois, le verbe est juste setNoun (), mais d'autres fois non. Cela dépend du nom. Par exemple:

my_vector.size() 

renvoie la taille et

my_vector.resize(some_size) 

change la taille.

Answer 6

L'approche groovy des propriétés est tout à fait excellent à mon humble avis, http://groovy.codehaus.org/Groovy + haricots

Answer 7

Les repères finaux de votre code devrait être ceci:

1. Est-ce que ça fonctionne correctement?
2. Est-il facile de fixer si elle se casse?
3. Est-il facile d'ajouter de nouvelles fonctionnalités à l'avenir?
4. Est-il facile pour quelqu'un d'autre à venir et fixer / l'améliorer?

Si ces 4 points sont couverts, je ne peux pas imaginer pourquoi quelqu'un aurait un problème. La plupart des « meilleures pratiques » sont généralement orientées vers la réalisation de ces 4 points.

Utilisation selon le style que fonctionne pour vous, être cohérent, et vous devriez être bien.

Answer 8

Ceci est juste une question de convention. En Smalltalk, il a fait la façon dont vous suggérez et je ne me souviens pas avoir jamais entendu personne se plaindre à ce sujet. Obtenir la vitesse est car speed de la voiture, et la mise en vitesse de la voiture à 55 est car speed:55.

Si je devais avancer une hypothèse, je dirais que la raison pour laquelle ce style n'a pas pris parce que des deux lignes vers le bas qui la programmation orientée objet sont venus nous: C ++ et Objective-C. En C ++ (encore plus tôt dans son histoire), les méthodes sont très étroitement liés aux fonctions C, et les fonctions C sont classiquement nommé le long des lignes de setWhatever() et ne pas surcharger pour différents nombres d'arguments, de sorte que le style général de nommer était conservé. Objective-C a été largement préservée par NeXT (qui est devenu plus tard Apple), et NeXT avait tendance à favoriser verbosité dans leurs API et surtout de faire la distinction entre les différents types de méthodes - si vous faites quoi que ce soit, mais juste accès à une propriété, NeXT voulait un verbe de préciser. Alors, qui est devenu la convention à Cocoa, qui est de facto la bibliothèque standard pour Objective-C ces jours-ci.

Answer 9

Il est convention Java a une convention de accesseurs C # a des propriétés, python a des champs publics et frameworks JavaScript ont tendance à utiliser le champ () pour obtenir et sur le terrain (valeur) pour définir

Answer 10

Au-delà d’une clarté sans ambiguïté, pourquoi devrions-nous nous en tenir à :car.getSpeed ​​() et car.setspeed (55) lorsque cela pourrait également être utilisé:car.speed() et car.speed(55)

Parce que dans toutes les langues que j'ai rencontrées, car.speed() et car.speed(55) sont les mêmes en termes de syntaxe.En les regardant comme ça, les deux pourraient renvoyer une valeur, ce qui n'est pas vrai pour ce dernier s'il était censé être un passeur.

Answer 11

Que faire si vous avez l'intention d'appeler le poseur, mais oublier de mettre dans l'argument? Le code est valide, de sorte que le compilateur ne se plaint pas, et il ne jette pas une erreur d'exécution immédiate; c'est un bug silencieux.

Answer 12

. () Signifie qu'il est un verbe. non () signifie qu'il est un nom.

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

   car.Speed()

implique commande de dépasser la limite de vitesse.