Classe avec méthode unique - meilleure approche?

Question

Dire que j'ai une classe qui est destiné à effectuer une seule fonction. Après l'exécution de la fonction, il peut être détruit. Est-il une raison de préférer l'une de ces approches?

// Initialize arguments in constructor
MyClass myObject = new MyClass(arg1, arg2, arg3);
myObject.myMethod();

// Pass arguments to method
MyClass myObject = new MyClass();
myObject.myMethod(arg1, arg2, arg3);

// Pass arguments to static method
MyClass.myMethod(arg1, arg2, arg3);

EDIT: j'ai été intentionnellement vague sur les détails, pour tenter d'obtenir des lignes directrices pour des situations différentes. Mais je n'ai pas vraiment avoir à l'esprit simple des fonctions de la bibliothèque comme les Mathématiques.random(). Je pense plus de classes que de réaliser certaines, tâche complexe, mais seulement besoin d'un (publique) de la méthode pour le faire.

Answer 1

J'ai l'habitude d'aimer les classes d'utilitaire rempli avec des méthodes statiques. Ils ont fait une grande consolidation des méthodes d'assistance qui seraient autrement mensonge autour de causer de la redondance et de la maintenance de l'enfer. Ils sont très facile à utiliser, pas d'instanciation, de l'absence de stockage, il suffit de le lancer n'forget. Je suppose que c'était ma première tentative inconsciente à la création d'une architecture orientée service - beaucoup de ces services qui n'ont fait que leur travail et rien d'autre. En tant que système pousse cependant, les dragons à venir.

Le polymorphisme
Disons que nous avons la méthode UtilityClass.SomeMethod qui heureusement se met à vibrer. Soudain, nous avons besoin de changer la fonctionnalité légèrement. Plus de la fonctionnalité est la même, mais nous devons changer quelques pièces tout de même. S'il n'avait pas été une méthode statique, on pourrait en faire un dérivé de la classe et de modifier la méthode de contenu en tant que de besoin. Comme c'est une méthode statique, nous ne pouvons pas. Bien sûr, si nous avons juste besoin d'ajouter des fonctionnalités que ce soit avant ou après l'ancienne méthode, nous pouvons créer une nouvelle classe et d'appeler l'ancien intérieur de celui-ci - mais c'est juste dégueulasse.

L'Interface de malheurs
Les méthodes statiques ne peuvent pas être définis par des interfaces pour des raisons de logique. Et puisque nous ne pouvons pas remplacer les méthodes statiques, les classes statiques sont inutiles quand nous avons besoin de passer par leur interface. Ce qui nous rend incapables d'utiliser les classes statiques dans le cadre d'un modèle de stratégie. Nous pourrions patch certaines questions par passage délégués au lieu d'interfaces.

Les tests
En fait cela va main dans la main avec l'interface malheurs mentionnés ci-dessus. Comme notre capacité d'interchanger les implémentations est très limité, nous allons aussi avoir des difficultés à remplacer la production de code avec le code de test. Encore une fois, nous pouvons emballer mais ça va nous obliger à changer de grandes parties de notre code juste pour être en mesure d'accepter des wrappers au lieu de les objets réels.

Favorise les blobs
En tant que méthodes statiques sont généralement utilisées comme méthodes de l'utilitaire et de l'utilité des méthodes ont généralement des besoins différents, nous allons rapidement se retrouver avec une grande classe rempli avec de la non-cohérent de fonctionnalités idéalement, chaque classe devrait avoir un but unique dans le système. Je préfère avoir un à cinq reprises les classes tant que leurs objectifs sont bien définis.

Paramètre de fluage
Pour commencer, que peu mignon et innocent méthode statique peut prendre qu'un seul paramètre. Comme la fonctionnalité de croissance, un couple de nouveaux paramètres ont été ajoutés. Bientôt, d'autres paramètres sont ajoutés qui sont optionnelles, nous créons des surcharges de la méthode (ou simplement ajouter des valeurs par défaut, dans les langues qui les prennent en charge). Avant longtemps, nous avons une méthode qui prend 10 paramètres. Seuls les trois premiers sont vraiment nécessaires, les paramètres de 4-7 sont facultatifs. Mais si le paramètre 6 est spécifié, 7-9 doivent être remplies aussi bien... A nous avons créé une classe dans le seul but de faire de ce que cette méthode statique n', nous avons pu résoudre ce problème en prenant les paramètres dans le constructeur, et en permettant à l'utilisateur de définir les valeurs facultatives grâce à des propriétés ou des méthodes pour définir plusieurs interdépendants valeurs en même temps. Aussi, si une méthode a grandi pour cette quantité de complexité, il est probable qu'il doit être dans sa propre classe, de toute façon.

Consommateurs exigeants à créer une instance de classes pour aucune raison
L'un des arguments les plus courants, c'est le pourquoi de la demande des consommateurs de notre classe créer une instance pour l'invocation de cette méthode unique, tout en ayant pas l'usage de l'instance par la suite? La création d'une instance d'une classe est un très très bon marché dans la plupart des langues, de sorte que la vitesse n'est pas un problème. En ajoutant une ligne de code à la consommation est un faible coût pour jeter les bases d'un beaucoup plus facile à gérer solution dans l'avenir. Et enfin, si vous voulez éviter de créer des cas, il suffit de créer un singleton wrapper de votre classe qui permet une réutilisation facile - même si c'est l'exigence que votre classe est apatride. Si ce n'est pas apatride, vous pouvez toujours créer statiques les méthodes de wrapper s'occupent de tout, tout en vous offrant tous les avantages à long terme. Enfin, vous pouvez également faire une classe qui cache l'instanciation comme si c'était un singleton: MyWrapper.Exemple est une propriété qui ne renvoie new MyClass();

Seulement un Sith traite dans l'absolu
Bien sûr, il existe des exceptions à mon aversion pour les méthodes statiques. La véritable utilité des classes qui ne posent aucun risque pour la météorisation sont d'excellentes affaires pour les méthodes statiques du Système.Convertir comme un exemple. Si votre projet est un one-off avec pas de besoins d'entretien, de l'architecture globale n'est vraiment pas très important - statique ou non statique, n'a pas vraiment d'importance - le développement de la vitesse, cependant.

Les normes, les standards, les normes!
À l'aide de méthodes d'instance n'inhibe pas vous aussi à l'aide de méthodes statiques, et vice versa. Tant qu'il y aura raisonnement à l'origine de la différenciation et il est standardisé. Il n'y a rien de pire que de regarder au-dessus d'une couche de gestion tentaculaire avec différentes méthodes de mise en œuvre.

Answer 2

Je préfère la manière statique. Étant donné que la classe ne représente pas un objet il n’est pas sensé faire une instance de celle-ci.

Les classes qui n’existent que pour leurs méthodes doivent rester statiques.

Answer 3

S’il n’y a aucune raison d’avoir une instance de la classe créée afin d’exécuter la fonction puis utiliser l’implémentation statique. Pourquoi faire les consommateurs de cette classe d’instancier quand on n’est pas nécessaire.

Answer 4

Si vous n’avez pas besoin d’enregistrer l' État de l’objet, puis il n’y a pas besoin d’instancier en premier lieu. J’irais avec la méthode statique unique que vous passez des paramètres.

Aussi, je mets en garde contre une classe Utils géante qui a des dizaines de méthodes statiques non apparentés. Cela peut devenir désorganisé et difficiles à manier à la hâte. Il est préférable d’avoir de nombreuses classes, chacun avec quelques méthodes connexes.

Answer 5

Je dirais que le format de la méthode statique serait la meilleure option. Et je voudrais faire la classe statique ainsi, de cette façon vous n’auriez à vous soucier accidentellement créant une instance de la classe.