Faut-il privilégier la cohérence par rapport à la convention de programmation?

Lors de la conception d'une classe, la cohérence des comportements doit-elle être privilégiée par rapport aux pratiques de programmation courantes? Pour donner un exemple précis:

Une convention courante est la suivante: si une classe possède un objet (par exemple, il l'a créé), elle est responsable de le nettoyer une fois qu'il est terminé. Un exemple spécifique serait dans .NET que si votre classe possède un IDisposableobjet, elle devrait le disposer à la fin de sa vie. Et si vous ne le possédez pas, ne le touchez pas.

Maintenant, si nous regardons la StreamWriterclasse dans .NET, nous pouvons trouver dans la documentation qu'elle ferme le flux sous-jacent lorsqu'elle est fermée / supprimée. Cela est nécessaire dans les cas où l' StreamWriterinstanciation en passant dans un nom de fichier en tant que scénariste crée le flux de fichiers sous - jacent et doit donc fermer. Cependant, on peut également passer dans un flux externe que l'écrivain ferme également.

Cela m'a énervé des tas de fois (oui, je sais que vous pouvez créer un wrapper non fermant, mais ce n'est pas le sujet), mais apparemment, Microsoft a décidé qu'il est plus cohérent de toujours fermer le flux, peu importe d'où il vient.

Lorsque je rencontre un tel modèle dans l'une de mes classes, je crée généralement un ownsFooBarindicateur qui est défini sur false dans les cas où il FooBarest injecté via le constructeur et sur true dans le cas contraire. De cette façon, la responsabilité de le nettoyer est transférée à l'appelant lorsqu'il passe explicitement l'instance.

Maintenant, je me demande si peut-être la cohérence devrait être en faveur des meilleures pratiques (ou peut-être que mes meilleures pratiques ne sont pas si bonnes)? Des arguments pour / contre?

Modifier pour clarification

Par «cohérence», je veux dire: le comportement cohérent de la classe prenant toujours la propriété (et fermant le flux) par rapport aux «meilleures pratiques» pour ne s'approprier un objet que si vous l'avez créé ou transféré explicitement la propriété.

Quant à un exemple où c'est énervant:

Supposons que vous ayez deux classes données (provenant d'une bibliothèque tierce) qui acceptent un flux pour en faire quelque chose, comme créer et traiter des données:

 public class DataProcessor
 {
     public Result ProcessData(Stream input)
     {
          using (var reader = new StreamReader(input))
          {
              ...
          }
     }
 }

 public class DataSource
 {
     public void GetData(Stream output)
     {
          using (var writer = new StreamWriter(output))
          {
               ....
          }
     }
 }

Maintenant, je veux l'utiliser comme ceci:

 Result ProcessSomething(DataSource source)
 {
      var processor = new DataProcessor();
      ...
      var ms = new MemoryStream();
      source.GetData(ms);
      return processor.ProcessData(ms);
 }

Cela échouera avec une exception Cannot access a closed streamdans le processeur de données. C'est un peu construit mais devrait illustrer le point. Il existe différentes façons de le réparer, mais j'ai néanmoins l'impression de contourner quelque chose que je ne devrais pas avoir à faire.

J'utilise aussi cette technique, je l'appelle «transfert», et je crois qu'elle mérite le statut d'un motif. Lorsqu'un objet A accepte un objet jetable B comme paramètre de temps de construction, il accepte également un booléen appelé `` transfert '' (qui par défaut est faux), et s'il est vrai, la suppression de A se répercute en cascade sur la suppression de B.

Je ne suis pas en faveur de la prolifération des choix malheureux des autres, donc je n'accepterais jamais la mauvaise pratique de Microsoft comme une convention établie, et je ne considérerais pas les autres aveugles suivant les choix malheureux de Microsoft comme un "comportement cohérent" de quelque manière, forme ou forme .

Je pense que vous avez raison, pour être honnête. Je pense que Microsoft a foiré la classe StreamWriter, en particulier, pour les raisons que vous décrivez.

Cependant, j'ai vu depuis beaucoup de code où les gens n'essaient même pas de disposer de leur propre Stream parce que le framework le fera pour eux, donc le réparer maintenant fera plus de mal que de bien.

J'irais avec cohérence. Comme vous l'avez mentionné à la plupart des gens, il est logique que si votre objet crée un objet enfant, il le possédera et le détruira. Si on lui donne une référence de l'extérieur, à un moment donné "l'extérieur" détient également le même objet et il ne devrait pas lui appartenir. Si vous souhaitez transférer la propriété de l'extérieur vers votre objet, utilisez les méthodes Attacher / Détacher ou un constructeur qui accepte un booléen qui indique clairement que la propriété est transférée.

Après avoir tapé tout cela pour une réponse complète, je pense que la plupart des modèles de conception génériques ne tomberaient pas nécessairement dans la même catégorie que les classes StreamWriter / StreamReader. J'ai toujours pensé que la raison pour laquelle MS avait choisi que StreamWriter / Reader reprenne automatiquement la propriété est parce que dans ce cas spécifique, avoir une propriété partagée n'a pas beaucoup de sens. Vous ne pouvez pas avoir deux objets différents simultanément en lecture / écriture dans le même flux. Je suis sûr que vous pourriez écrire une sorte de part de temps déterministe, mais ce serait un enfer d'anti-modèle. C'est probablement pourquoi ils ont dit, car cela n'a aucun sens de partager un flux, prenons toujours le relais. Mais je ne considérerais pas que ce comportement est devenu une convention générique à tous les niveaux pour toutes les classes.

Vous pouvez considérer que Streams est un modèle cohérent où l'objet qui est transmis n'est pas partageable du point de vue de la conception et donc sans aucun indicateur supplémentaire, le lecteur / écrivain prend simplement le relais.

Faites attention. Ce que vous pensez de la «cohérence» pourrait simplement être un ensemble aléatoire d'habitudes.

"Coordination des interfaces utilisateur pour la cohérence", SIGCHI Bulletin 20, (1989), 63-65. Désolé, pas de lien, c'est un vieil article. "... un atelier de deux jours de 15 experts n'a pas été en mesure de produire une définition de la cohérence." Oui, il s'agit de "l'interface", mais je pense que si vous pensez à la "cohérence" pendant un certain temps, vous constaterez que vous ne pouvez pas non plus la définir.