Je concevons l'API pour un service qui traite avec les entités code> code>. J'ai besoin de récupérer des emplois donné un statut. Donc, j'ai fini par nommer mes méthodes comme:
List<Job> getJobsAllButStatus(JobStatus status); List<Job> getJobsNotStatus(JobStatus status);
4 Réponses :
List<Job> jobLIst = getJobs(status, false);
J'ai choisi d'aller avec getjobsexcluingstatus . Merci.
+1 pour "La dactylographie n'est pas le goulot d'étranglement dans le développement de logiciels - c'est la pensée."
+1 Paramètres de méthode Boolean destinés à modifier son comportement doit être dactylographié de manière forte avec Enums.
List<Job> getJobsWithoutStatus(JobStatus status)
List<Job> Jobs.allWith(JobStatus... status); List<Job> Jobs.allBut(JobStatus... status); Combination of fluent api and varargs
Peut être ailleurs (jobstatus jobstatus) , allwherenot (jobstatus jobstatus)
Essayez de le garder simple -
List<Job> getJobsNotBelongTo(JobStatus status)
Peut-être getjobsbelongingto et getjobsnotbelongingto pour une meilleure grammaire.
D'accord, mais cela peut augmenter la longueur du nom de la méthode et de toute façon dans la programmation, grammer ne compte pas.
Cela peut être long, ce n'est pas un problème, mais la grammaire fait beaucoup de choses. Une méthode mal orthographiée / peu grammatisée entraîne immédiatement la intuitive de l'API que nous créons.
J'ai tendance à sentir que cette question devrait être fermée comme "non constructive" (pour tout site d'échange de pile). L'indice sur la fermeture des questions comme non constructive: " Cette question sollicitera probablement l'opinion, le débat, les arguments, interrogation ou une discussion prolongée. "
Ne serait-il pas préférable d'ajouter un paramètre booléen 'excluant', qui s'occuperait de cette fin. Si cela est vrai, retournez des travaux qui n'appartiennent pas à cet état et inversement. Juste une suggestion.
Quel est le problème avec non fermé en tant que statut de travail?
@Kurtdubois rien de mal, mais si j'ai besoin de récupérer des travaux qui sont
non fermés oune pas vivre ounon archivé et ainsi de suite, je vais doivent finir par créer de nombreuses méthodes différentes.@ C05mic Les paramètres booléens peuvent être plutôt déroutants, car ils ne sont pas très descriptifs à première vue où la méthode est invoquée.
Les paramètres booléens sont diaboliques et doivent être évités à tout prix :) Ils cachent essentiellement votre API intérieure des implications de la méthode.
@Kurtdubois: Comme le dit le premier commentaire, cette question a déjà sollicité des opinions. Quoi qu'il en soit, je suis d'accord avec votre point sur les paramètres booléens.
Peu importe ce que vous l'appelez aussi longtemps que cela a du sens et est bien documenté. Aucun de celles-ci aient de sens. Je conseillerais cependant que si chaque appel à la méthode passe le statut fermé, vous devriez peut-être simplement créer une méthode
getnononclejobs qui renvoie tout ce qui n'est pas fermé. Ne dites pas que vous ne pouvez pas appeler votre méthode quelque chose parce que ce sera générique. Est-ce un cas d'utilisation standard que les utilisateurs interrogeront le système pour tous les travaux sauf ceux qui ont un statut spécifique? (à part des emplois non fermés, qui semble un cas particulier)@ErickRobertson Absolument, c'est ainsi que ma couche suivante va exposer des méthodes (
getnonClosejobs ,getArchivedjobs etc.). Mais cette API est pour une couche interne à celle que le monde extérieur peut voir.@ADARSHR Puis le nom exact importe encore moins. Choisissez quelque chose que vous pensez a du sens et de le documenter.
Je pense que cette question est juste idiote et n'aide personne avec aucune connaissance. Comment nommer une méthode? Ah bon ?
La programmation est tout à propos de la communication claire. Une méthode mal nommée peut facilement masquer la signification du code bien écrit.
@mskfisher Aucun des choix OP proposés n'est médiocre. Ajouter une documentation et tout est bon.
@Erickrobertson - Je suis d'accord. Mon commentaire n'a pas été dirigé vers l'OP - c'était à l'origine un commentaire sur le commentaire d'Alexandrud (qui a été publié à l'origine comme une réponse).