méthodes utilitaires Homegrown

Question

méthodes utilitaires statiques sont généralement mal par puristes OO.

Je me demandais ce que les gens se sentent cependant sur les méthodes utilitaires qui sont utilisés pour éviter quelque chose de simple comme un chèque nul dans toute l'application.

String.trim() jette un NPE lorsqu'elle est appelée sur une chaîne vide. Donc, je dois faire:

if(str!=null) 
     setValue(str.trim());
else
     setValue("");

Que faire si je crée une méthode utilitaire qui vérifie l'hypothèse nulle?

setValue(myTrim(str));

public static String myTrim(String str) {

  if(str==null) return "" 

  else return str.trim();
}

Le seul problème que je l'ai rencontré avec des méthodes comme celles-ci est que certains développeurs de l'équipe pourraient ne pas aimer / ne pas savoir cet utilitaire et peut-être faire des appels STAIGHT après avoir fait une comparaison de valeur nulle.

Est-ce quelque chose que vous faites aussi votre cadre? Si oui, quelles sont les autres méthodes d'utilité commune d'usage général que les gens ont créé et utilisent dans leurs applications?

Que ressentez-vous les avantages et les inconvénients de ces deux approches?

Answer 1

Je serais enclin à remplacer le Homegrown utilise quand une bibliothèque existante (comme Apache Commons blablabla) a déjà écrit. Code vous pouvez décharger à quelqu'un d'autre vous permet de vous concentrer sur les parties importantes du logiciel qui différencie vraiment votre travail de tout le monde. Mais oui, les classes utilitaires avec des méthodes statiques sont grands, si elles doivent être écrites par vous du tout.

Pour votre information, jetez un oeil à StringUtils.trimToEmpty () . Bonne chance.

Answer 2

  

certains développeurs de l'équipe pourraient ne pas aimer / sais pas cet utilitaire

C'est ce que la communication est bon pour. Et je ne veux pas e-mail.

Les discussions sur ce genre de fonctions, probablement d'autres membres de l'équipe font la même chose et de ne pas communitating vous dupliquer le code et les efforts.

Vous pouvez trouver un moyen d'utiliser ces méthodes utilitaires ou même certains développeurs plus expérimentés migth déjà développer une lib plus mature ou utilisé une 3ème partie.

Mais par tous les moyens, communiquer avec votre L'équipe

Answer 3

Je ne suis pas un puriste OO. Donc, j'aime des trucs comme ça. Tout ce qui rend plus facile d'écrire du code qui reflète mes intentions sans se perdre dans les détails non pertinents.

écrire. Utilisez-le vous-même. Ne soyez pas timide - montrer combien il est propre votre code. Le pire des cas, au moins il y aura un peu moins de répétitions dans votre code ...

Answer 4

En ce qui concerne un principe de conception, il y a des choses qui sont plus logiquement des méthodes statiques. Si la classe utilitaire que vous écrivez n'a pas vraiment de tout « Etat », et il se sent plus logique de faire uninstantiable avec un tas de méthodes statiques, puis le faire comme ça. Mais assurez-vous que votre classe est vraiment uninstantiable (donner un constructeur privé, j'ai vu des gens déclarent la classe comme abstraite, mais ce n'est pas bon parce que les gens peuvent l'ignorer).

Le problème que vous obtenez alors en est que si votre classe est un projet à l'échelle, vous devez le traiter comme une classe de bibliothèque . Et les bibliothèques d'écriture est différente de l'écriture du code général:

• dans le code général, vous devriez le profil plutôt que d'optimiser prématurément; mais dans une méthode de bibliothèque, vous ne pouvez pas prédire comment les gens vont utiliser votre appel à l'avenir;
• vous devez être très prudent de documenter ou de nommer clairement ce que votre méthode fait;
• vous devez donner générique comportement, et ne pas être aveuglé par une caractéristique spécifique que vous avez besoin à ce moment-là (par exemple si vous avez une méthode pour « tokenise une chaîne », qu'est-ce que vous faites avec des jetons vides? si doivent les ignorer, seront autre appelants à votre méthode?)

Answer 5

J'ai quelques classes qui contiennent juste fave méthodes statiques - ils faire logique d'avoir. Vous pouvez mettre en place de nombreux tests unitaires et la vérification des toutes les conditions aux limites.

Dans le cas que vous avez décrit bien - ne serait-il préférable de faire la méthode setValue accepter toute chaîne qui lui est envoyé? La méthode pourrait ensuite appliquer une chaîne null par défaut, couper ou même jeter une exception si la valeur était incorrecte.

Le JavaDoc sur cette routine peut alors indiquer clairement ce que les entrées sont valides / invalides et ce qui se passe à des entrées non valides.

Ne dis pas que cela est juste - juste un autre point de vue

Answer 6

J'utilise beaucoup de fonctions d'utilité. Il y a des choses qui ne ne ont pas besoin des « objets », mais je n'aime pas l'exemple particulier que vous avez de trim ().

Une référence à chaîne est nulle est très différent d'une chaîne vide. À moins que l'application est très simple, et vous savez que vous voulez toujours que je ne lis nulle référence comme « », il. Dans ce cas, je préfère:

setValue((str != null) ? str.trim() : "")

Pour moi, une uncaught NPE est une bonne indication qu'il ya une erreur majeure en cours dans l'application!