Toutes les méthodes doivent-elles être statiques si leur classe n'a pas de variables membres

Question

Je viens de me disputer avec quelqu'un avec qui je travaille et ça me dérange vraiment. Si vous avez une classe qui n'a que des méthodes comme calculateRisk ou / et calculatePrice , la classe est immuable et n'a pas de variables membres, si les méthodes sont statiques pour ne pas avoir à créer une instance de la classe à chaque fois. J'utilise l'exemple suivant:

 public class CalcService {
  public int calcPrice(Trade trade, Date date) {
    ...
  }
  public double calcRisk(Trade trace, Date date) {
    ...
  }
}
 

Ces méthodes devraient-elles être static ?

Answer 1

La classe que vous décrivez n'est qu'un ensemble de fonctions qui ne fonctionnent que sur les entrées. Il est parfaitement raisonnable de faire de ces fonctions des méthodes statiques d'une classe. Cela les regroupe logiquement et élimine les conflits de noms possibles. La classe agit en fait comme un espace de noms et rien de plus.

Answer 2

Je dirais que oui, mais un argument pourrait également être avancé dans ce cas pour simplement mettre ces méthodes sur l'objet Commerce.

Answer 3

Il y a un sentiment général contre les classes statiques de ces jours, pour la testabilité des raisons.

C'est parce que les classes statiques ne peuvent pas mettre en œuvre une interface et ne peuvent donc pas être facilement substitué pour les classes de test si nécessaire. Je pense que ce type de cas qui traitent les prix sont un excellent exemple de cela. Il est possible qu'à l'avenir il peut y avoir plusieurs façons de calculer un prix, et il est agréable d'être capable de se substituer à ces calculatrices pour l'un de l'autre en tant que de besoin.

Il peut ne pas être utile, mais maintenant je vois plus d'avantages à ne pas utiliser une classe statique que d'utiliser une seule.

Answer 4

Je voudrais éviter de faire de ces statique. Alors que, dans le moment qui peut faire sens, vous pouvez, dans l'avenir voulez ajouter un peu de comportement. par exemple, au moment où on aurait un défaut moteur de calcul (stratégie):

CalcService cs = new CalcService();
cs.calcPrice(trade, date);

et plus tard, vous voudrez peut-être ajouter un nouveau moteur de calcul:

CalcService cs = new CalcService(new WackyCalculationStrategy());
cs.calcPrice(trade, date);

Si vous faites cette classe instantiatable, alors vous pouvez créer différentes instances et les transmettre autour de, instancier à la volée etc. Vous pouvez leur donner de la longue course de comportement (p. ex. le nombre de calculs impliquant des échanges X a cet objet fait ? etc.)

Answer 5

C'est une question difficile. Rappelez-vous ce que Josh Bloch dit à propos de l'Api:

Api, comme les diamants, sont pour toujours. Vous avez une chance de l'obtenir droit, de manière à lui donner votre meilleur.

(Cela peut ne pas être une API publique, mais si vous avez des collègues qui vont utiliser ce code, il est effectivement d'une API.) Si vous déclarez ces méthodes statiques, vous contraindre à leur évolution, et de l'incorporation de l'état dans la classe sera difficile, voire impossible. Vous allez avoir à vivre avec ces méthode statique signatures. Si vous décidez de les rendre non-statique en bas de la route parce que vous avez besoin de l'état, vous allez casser le code du client. Je dirais que, en cas de doute, ne pas les rendre statique. Cela dit, il y a une place pour la statique de l'utilitaire de classes qui contiennent un tas de fonctions (par exemple, calculer l'aire d'un cercle.) Votre classe peut tomber dans cette catégorie.