Noms des méthodes d'obtention des données

Question

Avertissement : C'est une question/discussion pas très sérieuse que je pose... mais je suis prêt à parier que la plupart des développeurs ont réfléchi à ce "problème"...

J'ai toujours voulu avoir l'avis d'autres personnes sur les conventions de dénomination des méthodes qui vont chercher des données quelque part et les renvoient...

La plupart des noms de méthodes sont assez simples et évidents... SaveEmployee() , DeleteOrder() , UploadDocument() . Bien entendu, pour les cours, vous utiliserez probablement la forme abrégée... Save() , Delete() , Upload() respectivement.

Cependant, j'ai toujours eu du mal avec l'action initiale... comment obtenir les données. Il semble que pour chaque projet, je finisse par passer d'une convention de dénomination à l'autre parce que je ne suis jamais satisfait de la dernière que j'ai utilisée. Pour autant que je sache, voici les possibilités -->

• GetBooks()
• FetchBooks()
• RetrieveBooks()
• FindBooks()
• LoadBooks()

Quelle est votre pensée ?

Answer 1

Il s'agit d'être cohérent sémantique ;

Dans le titre de votre question, vous utilisez obtenir des données . Ceci est extrêmement général dans le sens où il faut définir ce que l'on entend par obtenir moyens de manière sémantiquement significative et non ambiguë. Je propose les exemples suivants pour vous mettre sur la bonne voie lorsque vous réfléchissez à la notion de de nommer les choses.

1. getBooks() c'est lorsque vous obtenez tous les livres associés à un objet cela implique que les critères de l'ensemble sont déjà définis et que leur provenance est un détail caché.
2. findBooks(criteria) c'est lorsque l'on cherche à trouver un sous-ensemble des livres sur la base de paramètres à l'appel de la méthode, il s'agira généralement sera généralement surchargé avec différents critères de recherche. critères
3. loadBooks(source) c'est lorsque vous êtes chargement à partir d'une source externe, comme un fichier ou une base de données.
4. Je n'utiliserais pas fetch/retrieve parce qu'ils sont trop vagues et qu'ils sont confondus avec obtenir et il n'y a pas de sémantique univoque associée aux termes.

Ejemplo: rechercher implique qu'une entité doit aller chercher quelque chose d'éloigné et le ramener. Les chiens vont chercher un bâton, et récupérer est un synonyme de rechercher avec la sémantique supplémentaire que vous pouvez avoir été en possession de la chose auparavant. obtenir est un synonyme de obtenir ce qui implique que vous êtes le seul à posséder quelque chose et que personne d'autre ne peut l'acquérir simultanément.

Sémantique sont extrêmement importants :

la branche de la linguistique et de la logique qui s'intéresse au sens

Les commentaires sont la preuve que des termes génériques tels que obtenir y rechercher ont n'ont pas de sémantique spécifique et sont interprétées différemment selon les personnes. personnes. Choisir une sémantique pour un terme, documenter ce qu'il est censé Si la sémantique n'est pas claire, documentez ce qu'elle implique et soyez cohérent avec son utilisation.

Les mots dont le sens est vague ou ambigu se voient attribuer une sémantique différente selon les personnes, en raison de leurs préjugés et de leurs idées préconçues fondés sur leurs opinions personnelles, ce qui n'est jamais une bonne chose.

Answer 2

Honnêtement, vous devriez décider avec votre équipe de la convention de dénomination à utiliser. Mais pour le plaisir, voyons quel serait votre cheminement de pensée pour décider de l'une ou l'autre de ces conventions :

• GetBooks()

Cette méthode appartient à une source de données, et nous ne nous soucions pas de la manière dont elle les obtient, nous voulons simplement les obtenir de la source de données.

• FetchBooks()

Vous traitez votre source de données comme un limier, et c'est à lui qu'incombe la tâche d'aller chercher vos livres. Je suppose que vous devez décider vous-même du nombre de livres qu'il peut tenir dans sa bouche en une seule fois.

• Trouver des livres()

Votre source de données est un bibliothécaire et utilisera le système décimal de Dewey pour trouver vos livres.

• Charger les livres()

Ces livres se trouvent dans une sorte de "sac à livres électroniques" et doivent y être chargés. Veillez à appeler ZipClosed() après le chargement pour éviter de les perdre.

• Récupérer les livres()

Je n'ai rien.

Answer 3

La réponse est de s'en tenir à ce qui vous convient et d'être cohérent.

Si vous avez un site web barnes and nobles et que vous utilisez GetBooks(), alors si vous avez un autre élément comme une entité Movie, utilisez GetMovies(). Faites donc ce que vous et votre équipe aimez et soyez cohérent.

Answer 4

Ce que vous entendez par "obtenir les données" n'est pas clair. De la base de données ? D'un fichier ? De la mémoire ?

Selon moi, le rôle de la dénomination des méthodes est d'éliminer toute ambiguïté et, dans l'idéal, d'éviter d'avoir à consulter la documentation. Je pense que cela devrait être fait même au prix de noms de méthodes plus longs. Selon des études, la plupart des développeurs de niveau intermédiaire+ sont capables de lire plusieurs mots en camel case. Avec l'IDE et les complétions automatiques, écrire de longs noms de méthodes n'est pas non plus un problème.

Ainsi, lorsque je vois "fetchBooks", à moins que le contexte ne soit très clair (par exemple, une classe nommée BookFetcherFromDatabase), c'est ambigu. D'où proviennent les livres ? Quelle est la différence entre fetch et find ? Vous vous exposez également au risque que certains développeurs associent la sémantique à certains mots-clés. Par exemple, rechercher dans la base de données (ou la mémoire) par rapport à charger (à partir d'un fichier) ou télécharger (à partir du web).

Je préférerais voir quelque chose comme "fetchBooksFromDatabase", "loadBookFromFile", "findBooksInCollection", etc. C'est moins visible, mais une fois qu'on a surmonté la longueur, c'est clair. Toute personne lisant ceci comprendra immédiatement ce que vous essayez de faire.

Answer 5

En OO (C++/Java), j'ai tendance à utiliser getSomething et setSomething parce que très souvent, sinon toujours, j'obtiens un attribut privé de la classe représentant cet objet de données ou je le définis - la paire getter/setter. De plus, Eclipse les génère pour vous.

J'ai tendance à n'utiliser Load que lorsque je parle de fichiers - comme dans "load into memory" (charger en mémoire) et cela implique généralement le chargement de primitives, de structures (C) ou d'objets. J'utilise send/receive pour le web.

Comme nous l'avons dit plus haut, la cohérence est essentielle, y compris entre développeurs.