Ne pas utiliser "statique" en C #?

J'ai soumis une demande que j'ai écrite à d'autres architectes pour la révision du code. L'un d'entre eux m'a presque immédiatement répondu en me disant "N'utilisez pas" statique ". Vous ne pouvez pas écrire de tests automatisés avec des classes et des méthodes statiques." Statique "est à éviter."

J'ai vérifié et au moins 1/4 de mes cours sont marqués "statique". J'utilise static lorsque je ne vais pas créer une instance d'une classe car cette classe est une classe globale unique utilisée dans le code.

Il a ensuite mentionné quelque chose impliquant des techniques moqueuses, CIO / DI qui ne peuvent pas être utilisées avec du code statique. Il dit qu'il est regrettable que des bibliothèques tierces soient statiques en raison de leur caractère non testable.

Est-ce que cet autre architecte a raison?

mise à jour: voici un exemple:

APIManager - cette classe conserve les dictionnaires des API tierces que j'appelle avec la prochaine heure autorisée. Il impose les limites d'utilisation des API que de nombreuses tierces parties ont dans leurs conditions de service. Je l'utilise n'importe où j'appelle un service tiers en appelant Thread.Sleep (APIManager.GetWait ("ProviderXYZ")); avant de faire l'appel. Tout ici est thread-safe et cela fonctionne très bien avec le TPL en C #.

Cela dépend si les classes statiques conservent ou non l'état. Personnellement, je n’ai aucun problème avec les fonctions sans état jeté ensemble dans une classe statique.

Il est trop général à ce sujet. Il a raison, cela empêche les tests. Cependant, les staticclasses et les méthodes ont leur place et cela dépend vraiment du contexte. Sans exemples de code, vous ne pouvez pas vraiment dire.

J'utilise static lorsque je ne vais pas créer une instance d'une classe car cette classe est une classe globale unique utilisée dans le code.

Cela peut être une odeur de code grave. Pourquoi utilisez-vous les cours? Pour stocker des données? Pour accéder à une base de données? Alors il a raison. Dans ce cas, vous devriez regarder l'injection de dépendance, car une telle classe statique est en réalité un singleton implicite.

Si vous les utilisez pour des méthodes d'extension ou des aides qui ne changent pas l'état et se contentent d'agir sur les paramètres que vous fournissez, ceux-ci fonctionnent normalement.

J'ai vérifié et au moins 1/4 de mes cours sont marqués "statique". J'utilise static lorsque je ne vais pas créer une instance d'une classe car cette classe est une classe globale unique utilisée dans le code.

La meilleure chose à faire est d'essayer de tester votre code. Essayez de concevoir des tests répétables, indépendants, simples et ne testez qu'une méthode à la fois. Essayez d'exécuter vos tests dans un ordre aléatoire différent. Pouvez-vous obtenir une construction "verte" stable?

Si oui, c'est un argument valable pour défendre votre code. Si, toutefois, vous rencontrez des difficultés, alors vous devriez peut-être utiliser des méthodes basées sur des exemples.

Les réponses déjà publiées couvrent de très bons points, mais il en manque un:

Les champs statiques ne sont jamais collectés.

Ceci est vraiment important si vous avez une application avec beaucoup de contraintes de mémoire, et ce schéma peut être très courant lorsque des personnes tentent d'implémenter un cache.

Les fonctions statiques ne sont pas aussi mauvaises, mais tout le monde a déjà couvert cela assez en détail.

Un des avantages de l'IoC / DI est que la plupart des interactions entre les classes sont négociées entre interfaces. Cela facilite les tests unitaires car les interfaces peuvent être simulées automatiquement ou semi-automatiquement. Par conséquent, chacune des pièces peut être testée pour les entrées et les sorties. De plus, au-delà de la testabilité, le fait de mettre des interfaces entre tous les éléments vous permet d’avoir le code le plus modulaire possible. Vous pouvez facilement remplacer une implémentation sans trop vous inquiéter des dépendances.

Comme C # n'a pas de métaclasse, une classe ne peut pas implémenter une interface utilisant des fonctionnalités statiques, aussi les fonctionnalités statiques des classes entravent-elles tout effort d'implémentation d'un modèle d'objet IoC / DI pur. C'est-à-dire que vous ne pouvez pas créer de maquette pour les tester, vous devez créer de vraies dépendances.

Si votre entreprise / projet est lourdement investi dans l'IoC, il s'agit bien sûr d'une préoccupation raisonnable, et la douleur que vous vivez est au profit de tous. D'un point de vue architectural, cependant, je ne pense personnellement pas que tout modèle devrait être suivi jusqu'à la tombe. Il y a des choses qui ont du sens à implémenter en utilisant des méthodes statiques - la stratégie de conception de singleton, par exemple. Je suis moi-même moins enclin aux classes statiques car je pense qu'elles ont tendance à perdre de plus en plus les avantages de OO, mais il arrive parfois qu'une classe de bibliothèque soit probablement l'expression plus naturelle de quelque chose qu'un moteur.

Le commentateur me rappelle les méthodes d'extension, qui doivent bien sûr être dans des classes statiques en C #. C’est légitime, et c’est un exemple de la façon dont IoC pur ne fonctionne pas très bien en C #, du moins si vous essayez de tirer parti de l’ampleur du langage.

Les classes statiques sont parfois mal utilisées et devraient être:

• un singleton (où la classe non statique a un membre statique et une variable d'instance statique publique pour le récupérer / le créer une seule fois.
• une méthode dans une autre classe (où l'état compte). Si un membre n'utilise aucune donnée de cette classe, il ne devrait probablement pas en faire partie.

Il peut également s'agir d'une fonction dite "d'utilitaire" et d'une partie d'une classe d'utilitaires. Les classes d'utilitaires sont des classes qui ne contiennent que des méthodes statiques et servent de fonctions d'assistance sans contexte.

Les méthodes statiques sont faciles à utiliser et ont la place qui leur revient dans la programmation. Il semble que votre architecte dispose d'un cadre de test qui ne prend pas complètement en charge les méthodes statiques. Si votre code fait partie d'un projet plus important, il est important de respecter les directives de l'architecte. Cependant, ne laissez pas ce projet vous dissuader d'utiliser des méthodes statiques lorsque cela est approprié.

J'utilise des propriétés statiques pour des éléments communs à toutes les instances d'une classe. Et j'ai utilisé des méthodes statiques pour obtenir des groupes d'objets de classe. Je ne suis en aucun cas un expert, mais cela a fonctionné pour moi jusqu'à présent.

Exemple PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

Je dirai que leurs principes sont corrects mais que la déclaration (n'utilisez pas de statique) peut être fausse. Combien coûte votre couverture de code? si le nombre est élevé et que vous êtes à l'aise avec les tests unitaires de votre application, vous êtes ok. Si non, alors je suggérerais de revoir le code. Vous pouvez trouver que les classes statiques sont la raison ou non, cela dépendra de beaucoup de choses.

Les classes utilisant des méthodes statiques abusent des principes de la programmation orientée objet. Ce n'est pas déjà une POO, c'est COP - une programmation orientée classe.

Ils ont rarement une "personnalité" claire (j'utilise ma métaphore humaine préférée ici), ou une identité. Donc, ils ne savent pas qui ils sont. Ce point suffit à lui seul à se débarrasser de ce concept en POO, mais il y en a plus.

Le suivant est une conséquence du premier point. Étant donné que ces classes ne savent pas qui elles sont, elles ont tendance à être très grandes.

La troisième rend votre code absolument non maintenable. L'utilisation de méthodes statiques introduit des dépendances cachées . Ils apparaissent partout et vous ne savez jamais ce qui se passe dans votre classe. Vous ne pouvez pas en être sûr simplement en regardant la signature du constructeur.

Lentement mais inévitablement, votre code devient de moins en moins cohérent, car les dépendances cachées sont mal contrôlées. Ils semblent invisibles. Et c'est si facile d'en ajouter un autre! Vous ne devez modifier aucune signature de méthode. Tout ce que vous avez à faire est d'appeler une méthode statique. Et quel code laid suit ...

Ok, vous avez probablement déjà deviné. Le couplage serré est souvent associé à une faible cohésion. Si de nombreux clients utilisent une classe, le couplage se resserre. Et il y a une grande séduction à utiliser une classe ou une méthode déjà écrite qui ne nécessite qu'une correction minime. Un seul paramètre indicateur-méthode.

Quoi utiliser à la place des méthodes statiques? Eh bien, ma suggestion est la POO. Pourquoi ne pas essayer?