Méthodes d'assistance privées par rapport aux méthodes d'utilité statique publique dans Java
J'ai une classe Java qui devient longue. Lorsque je l'exécute via des outils de qualité de code, je suis signalé pour le nombre de lignes dans la classe.
Ceci est une classe de couche inférieure, utilisée par les couches supérieures avec Spring's@Autowired. La classe a beaucoup de méthodes d'instances privées qui ne sont pas statiques. Ils n'utilisent aucun champ d'instance, travaillant uniquement sur les paramètres de méthode.
Puis-je déplacer ces méthodes en toute sécurité en tant que public static dans une classe d'utilité distincte? Quels sont les inconvénients?
"Mauvais" état d'esprit ici.
Vous ne retravaillez pas vos classes car les outils se plaignent de ceci ou de cela.
Vous souhaitez améliorer la qualité de votre code source; et ces outils peuvent aider à identifier les "sujets qui méritent réflexion". Vous prenez leurs commentaires comme indice; pas comme "ordre".
Par conséquent, vous ne vous souciez pas des "lignes de codes" au sein d'une classe. Au lieu de cela, vous vous inquiétez des responsabilités de cette classe. Signification: le nombre de lignes n'est pas un problème en soi - mais les violations du principe de responsabilité unique le sont.
Ainsi: vous reculez et vérifiez exactement ce que fait votre classe. Et quand il fait clairement plus d'une chose, vous extrayez ces aspects dans d'autres classes!
Signification: si vous trouvez réellement que tout ce code "appartient" à la responsabilité de cette classe; puis gardez-le là-dedans. Ne commencez pas à mettre détails de l'implémentation interne dans des classes auxiliaires indépendantes; juste parce que certains outils vous avertissent du nombre de lignes.
D'un autre côté, transformer des méthodes privées en quelque chose de statique/protégé par package vous permettrait de tester ces méthodes à l'unité. Ce qui pourrait être un avantage. Mais comme dit: tant que nous parlons de détails d'implémentation, ils doivent rester privés; et ils ne devraient pas être testés de toute façon.
Code de longue histoire: savoir et comprendre ce qu'est le "code propre"; et essayez de suivre les idées qui y sont décrites.
La division des méthodes devrait être par objectif/application/logique (vous l'appelez), et non par propriétés techniques.
Un code source long peut probablement être séparé en plusieurs classes de petite taille, chacune ayant son propre objectif/responsabilité.
J'utilise constamment des classes utilitaires qui contiennent des méthodes statiques et je trouve cela très pratique. Si les méthodes sont réellement destinées à une seule classe, vous pouvez placer votre classe Utility en tant que classe privée statique dans votre classe d'origine. Mais j'ai découvert que dans de nombreux cas, les méthodes générales d'utilité statique peuvent être utilisées par plusieurs classes, donc dans ce cas, je créerais une classe d'utilité distincte avec un ensemble de méthodes statiques qui pourraient être utilisées par plusieurs classes.
De plus, je suis fortement d'accord avec la réponse de GhostCat en termes de pensée générale. Quant à la taille d'une classe - cela pourrait être un problème, mais en général, je ne m'inquiète pas beaucoup. Ce que je recherche vraiment, c'est la taille de vos méthodes. J'aime que les méthodes soient courtes et explicites, en commençant par son nom et les noms et l'ordre des paramètres et par la logique. S'il y a un gros morceau de logique interne - extrayez-le dans une méthode distincte. Cela rend le code beaucoup plus lisible et maintenable.
La qualité du code ne peut pas être mesurée par le nombre de lignes. Si vous constatez que le fichier de classe grandit de jour en jour, assurez-vous que votre classe suit le principe de responsabilité unique.
Lorsque votre classe ne suit pas le principe, séparez-les en classes individuelles et transformez les classes en un package.
Sinon, vous pourriez faire de votre classe de base un classe abstraite et faire vos méthodes util comme abstract. Avoir une classe enfant qui étend la classe de base fournissant l'implémentation de méthodes abstraites dans la classe de base.
Voici une bonne SO donc réponse à quand vous pourriez rendre vos méthodes statiques
Comme l'a dit @Zack Jannsen,
"statique" est souvent utile lorsque vous savez que quelque chose ne changera pas entre les instances. Si tel est le cas, je considérerais vraiment le "principe de responsabilité unique", qui implique qu'une classe devrait avoir une responsabilité et donc une seule raison de changer. Je pense que l'on devrait envisager de déplacer la fonction "ConvertMpgToKpl (double mpg)", et des méthodes similaires, dans leur propre classe. Le but d'un objet de voiture est de permettre l'instanciation des voitures, et non de fournir une comparaison entre elles. Ceux-ci devraient être externes à la classe.
Bien que statique vous permette d'accéder à la méthode sans création d'objet, rappelez-vous toujours ce qui suit lorsque vous essayez de rendre la méthode statique
- La méthode produit un résultat cohérent basé sur les arguments d'entrée
- Vous avez toujours besoin que cette méthode soit en mémoire (c'est-à-dire que vous avez besoin de la méthode assez souvent) - Il pourrait être préférable d'accéder à une énorme méthode qui ne serait accessible que très peu de fois à l'aide de la création d'objets plutôt que d'y accéder via
static - Les méthodes utilitaires qui sont utilisées assez souvent pourraient être faites comme
static