Ce qui est un bon nom pour une méthode qui obtient ou crée un objet?

Dire que vous avez un cache, et une méthode qui permettra de faire quelque chose comme ce qui suit:

if (wanted Foo is not in cache)
    cache.Add(new Foo())
Return Foo from cache

Que feriez-vous appel à cette méthode? GetFoo(), GetOrCreateFoo() ou quelque chose d'autre (et mieux)? Ou cela doit-il vraiment être divisé en deux méthodes?

InformationsquelleAutor Tor Livar | 2010-07-06
  1. 28

    Dans la plupart des cas, un simple GetFoo suffit que l'appelant n'a pas besoin de savoir que vous êtes la création et la mise en cache il. C'est ce que l'encapsulation est tout au sujet.

    Cependant, dans certains cas, la création est une opération coûteuse, il est donc utile de savoir que vous pouvez être en train de créer quelque chose sur la demande et, dans certains cas, il sera lente. Dans ce cas, une convention de dénomination rend plus clair de l'appelant. Dans ce cas, un GetOrCreate() ou Get(Options.CreateIfMissing) est un bon indicateur de l'appelant.

    (Le comportement doit être indiqué dans la documentation, mais il est bon d'utiliser un nom de méthode qui rappelle aux gens au sujet des effets secondaires pendant la lecture du code, sans avoir à afficher et de lire la documentation pour chaque méthode qui est appelée)

    Le genre de cas, je trouve cela passe le plus souvent est (par exemple) lors de la recherche d'un nœud de l'arborescence (par exemple dans un document Xml), vous pourriez avoir "CreateNode" (pour créer un nœud sans ajouter à l'arbre) et "AddNode" (pour ajouter un nœud de l'arbre). Dans ce cas, "d'Ajouter un nœud si elle n'existe pas déjà" doit avoir un autre nom descriptif, donc je vais utiliser quelque chose comme "EnsureNodeExists" afin de les différencier et de faire le but clair.

    • Vous devez généralement fournir un get avec une sorte de clé unique. Dans ce cas, vous êtes probablement pas à la recherche d'une clé spécifique, mais pour différentes valeurs de colonnes, de sorte qu'un getFooByWhatever pourrait être adapté (évidemment pas en fait à l'aide de whatever).
    • J'aime la CreateIfMissing libellé. Nice!
    InformationsquelleAutor Jason Williams
  2. 17

    Je sais je suis très en retard sur la question, mais ce que je peux proposer GrabFoo() de la convention pour obtenir-ou-créer-si-il vous manque afin de la différencier de GetFoo()?

    À la recherche à la synonymes de Get, je vois plusieurs convenables des verbes, certains sont déjà couramment utilisé comme méthode de verbes. Par exemple, Fetch déjà connote aller chercher quelque chose à partir d'un système externe. (par exemple, base de données ou d'un réseau)

    Grab semble être rarement utilisé, et peut-être porteurs d'une (quoique faible) sémantique de la I want you to get-or-create it, no matter what.

    InformationsquelleAutor Ibrahim Arief
  3. 7

    Comment sur Getsert? de get ou insert, depuis update ou insert est Upsert

    Si je n'ai pas vu de populaire cadres de l'utilisation de ce terme, mais ceci est conforme à l'idée que @Jason Williams a souligné, que:

    • il devrait être clair pour l'utilisateur qu'il ne serait pas juste de faire une activité normale obtenir
    • Vous n'avez pas à aller à la documentation pour voir ce qu'il fait
    • Facile à la collecte et intuitive? (Je ne suis pas sûr)
    • Je pense que GetFoo() n'est pas clair, car il n'a pas l'appelant de savoir si ils vont obtenir un résultat vide ou pas, si l'objet n'existe pas déjà. Donc Getsert serait plus clair.
    • J'aime le mot-valise idée, mais Getsert me fait penser à get + assert, qui a un sens différent.
    InformationsquelleAutor Louie Almeda
  4. 5

    Ma préférence est GetFoo(), que l'action du point de vue de l'appelant et le cache est plus d'un détail d'implémentation.

    InformationsquelleAutor Ofir
  5. 3

    Je l'appellerais GetFoo, au motif que la appelant ne se soucie pas de savoir s'il va être donné un nouveau ou déjà créés Foo - il veut juste Get un Foo.

    InformationsquelleAutor AakashM
  6. 2

    D'un cache, je voudrais simplement appeler GetFoo(). Un cache est conçu pour agir comme une façade derrière une source de données afin que les utilisateurs puissent facilement accéder à des éléments sans se soucier de la façon dont ils sont ou ne sont pas en cours de chargement.

    Je l'appellerais GetFoo, mais le document que si l'objet demandé n'est pas dans le cache, le cache pour le charger (et tout le potentiel de performance des répercussions que pourrait avoir).

    InformationsquelleAutor Alex Humphrey
  7. 2

    Une autre option qui a de sens que si vous êtes référentielle transparent ou l'objet est un singleton.

    Parfois un getOrCreate() appel est vraiment paresseux de l'initialisation. Ainsi, vous voulez créer un objet et si elle a déjà été créé à renvoyer une référence. Dans ce cas, je voudrais appeler la méthode lazyGet qui est aussi utilisé dans d'autres bibliothèques, comme javaslang paresseux.

    MyObject lazyGet() {
}

    Cela a un avantage sur le site d'appel. Si votre appel est coûteux dans un contexte de création de votre destinataire sait que désireux d'initialisation peuvent être utilisées pour déplacer le coût de l'appel pour un non section critique de votre programme.

    P. S.: Il est aussi utilisé pour memoization, qui est une technique d'optimisation où vous retournez les Objets mis en cache de données immuables-structures.

    InformationsquelleAutor Alex
  8. 2

    Les mots obtain et acquire semblent être bien équipé. Surtout obtain:

    à entrer en possession de; obtenir, acquérir, ou de se procurer, par le biais d'une
    l'effort ou par une demande: pour obtenir la permission; pour obtenir une meilleure
    revenu.

    On pourrait dire que dans votre cas, l'appelant de la méthode obtient le foo.

    InformationsquelleAutor Isinlor
  9. 1

    J'irais pour seulement GetFoo() tout comme la plupart des gens ont mentionné ici.

    Raison est - La méthode est responsable du retour de l'instance de l'objet. C'est sa principale responsabilité. Si l'objet n'est pas créé, puis de créer l'objet mis en cache, puis le retourner. les appelants externes, n'a pas besoin de s'embêter quelle méthode interne ne retourner l'objet, les appelants appellent simplement GetFoo() chaque fois que nécessaire. Méthode GetFoo() encapsule et masque la complexité de la création et de la mise en cache de l'objet. donc GetFoo()

    InformationsquelleAutor this. __curious_geek
  10. 1

    Je sais que le sujet a 6 ans. Mais... je pense que le meilleur nom est 

    getInstanceFoo()

    ou

    getFooInstance()

    comme dans la classe singleton.

    InformationsquelleAutor Lasek
  11. 1

    - Je utiliser Take au lieu de Get. Pourquoi:

    • take aussi sonne un peu comme make
    • à take a le même sens que get dans le contexte donné
    • take sons plus puissante que les get, donc si je ne peux pas get, je vais juste take il
    InformationsquelleAutor mchlstckl
  12. 1

    Engendrent

    Quelques définitions qui semblent correspondre:

    • À cause d'exister ou de se produire, à produire de l'
    • De la cause ou de créer

    Le mot se décompose en deux idées dans votre question.

    "Qu'est ce qu'un bon nom pour une méthode qui obtient ou crée un
    objet?"

    Être = crée

    Obtenir = obtient

    Plus de sa très courte.

    Une autre alternative est Résoudre.

    J'emprunte ce mot à partir de Autofac, qui utilise Régler les modalités de vous obtenir une instance d'un objet, ou le créer si nécessaire.

    InformationsquelleAutor Casey
  13. 0

    Je dirais que c'est "getFoo()" et les ajouter à vos commentaires ce que la fonction ne s'Foo n'est pas nulle.

    • -1 Le nom doit transmettre ce que la méthode est le cas, vous ne devriez pas besoin d'un commentaire. Aussi, je ne m'attends pas à un 'get' fonction pour avoir des effets secondaires tels que la création de quelque chose.
    InformationsquelleAutor InsertNickHere
  14. 0

    Cela dépend de quel type d'objet qui ont du sens pour l'utilisateur.

    Si la création n'est pas important pour l'utilisateur, il est GetFoo; sinon, appeler createOrGetFoo.

    Si la différenciation des concepts est nécessaire, vous pourriez avoir des méthodes comme GetFoo, CreateFoo et createOrGetFoo.

    Je préfère le nom que GetFoo en fonction de votre information.

    InformationsquelleAutor OmniBus
  15. 0

    En supposant que cette méthode est sur un cacheManager puis fetch(voulu) [ou get(voulu) en fonction de votre pref] est assez - avec l'API doc indique que l'élément est créé si il n'existe pas.

    Voulais qui doit être tapé en conséquence, il n'ya donc pas besoin de Foo dans le nom de la méthode.

    InformationsquelleAutor dasher
  16. -1

    Si cette conception est tout à fait logique dans votre application, puis je pense que GetOrCreateFoo est un nom approprié.

    Une autre approche, qui expose clairement son but serait

    GetFoo(bool createIfNotExists)

    Bien sûr, si nous sommes réellement en train de parler cache la mise en œuvre de côté pourrait ne pas se préoccuper de savoir si ou non l'élément a été créé. Le ci-dessus s'applique dans les cas où l'appelant a fait réellement besoin de savoir à propos de la possible création d' Foo et de ses implications (comme lors de la récupération du système de fichiers ou une base de données, peut-être?)

    • GetOrCreateFoo : Je ne suis pas d'accord ici. La méthode devient l'objet de foo, si elle n'est pas créée, il va créer l'objet, le mettre en cache et retourne l'objet. la création et la mise en cache est trop interne à l'avant-plan de la méthode doivent donc pas être GetOrCreateFoo.
    • Je suis d'accord avec que, dans le cas spécifique de la mémoire cache, mais la question est "qu'est ce qu'un bon nom pour une méthode qui obtient ou crée un objet" et dans le cas plus général, il peut très bien y avoir des cas où l'appelant ne veux plus le contrôle de ce (tenir compte de la très utile FileMode.OpenOrCreate dans System.IO.File.Open)
    • L'ajout d'un argument booléen à un getter pour ajouter cette fonctionnalité n'a pas d'améliorer la lisibilité, sauf si vous utilisez un langage de programmation avec des paramètres nommés.
    InformationsquelleAutor David Hedlund