Problème de compréhension du mot «couture»

Je lis "Dependency Injection in .NET" de Mark Seemann (c'est fantastique, et doit l'avoir) et l'auteur utilise souvent le mot "couture". Mais je ne comprends pas ce que cela signifie. Voici un exemple d'utilisation de ce mot:

Le chapitre 7 explique comment composer des objets dans divers cadres concrets tels que ASP.NET MVC, WPF, WCF, etc. Tous les frameworks ne prennent pas aussi bien en charge DI, et même parmi ceux qui le font, les façons dont ils le font diffèrent beaucoup. Pour chaque cadre, il peut être difficile d'identifier le SEAM qui permet DI dans ce cadre. Cependant, une fois que SEAM est trouvé, vous avez une solution pour toutes les applications qui utilisent ce cadre particulier. Au chapitre 7, j'ai effectué ce travail pour les frameworks d'application .NET les plus courants. Considérez-le comme un catalogue de framework SEAMS.

Je vous serais reconnaissant de m'aider à comprendre ce mot.

Je pense que le terme provient de Michael Feathers Working Effectively with Legacy Code dans lequel il explique une couture dans un logiciel comme un endroit où deux parties du logiciel se rencontrent et où autre chose peut être injecté. L'analogie est une couture dans les vêtements: l'endroit où deux parties sont cousues ensemble. La pièce de chaque côté ne touche que l'autre juste au niveau de la couture. Retour au logiciel: Si vous identifiez la couture, vous avez identifié l'endroit où il y a une interface bien définie. C'est ce que vous pouvez exploiter en DI, car une telle interface vous permet de remplacer l'implémentation sans que le reste du logiciel puisse le dire (sans tricher de toute façon).

S'appuyant sur la réponse de Christian, au meilleur de ma connaissance, le terme couture provient du livre de Feathers, Working Effectively with Legacy Code . La définition se trouve à la page 31:

Une couture est un endroit où vous pouvez modifier le comportement de votre programme sans modifier à cet endroit.

Pour donner des exemples de ce qu'est une couture et de ce qu'elle n'est pas, considérez le code Java suivant:

public class MyClass {
  private final Foo foo;

  public MyClass(Foo foo) {
    this.foo = foo;
  }

  public void doBunchOfStuff(BarFactory barFactory) {
    // foo.doStuff() is a seam because I can inject a mock instance of Foo
    this.foo.doStuff();

    // barFactory.makeBars() is a seam because I can replace the default
    // BarFactory instance with something else during testing
    List<Bar> bars = barFactory.makeBars();
    for(Bar bar : bars) {
      // bar.cut() is also a seam because if I can mock out BarFactory, then
      // I can get the mocked BarFactory to return mocked Bars.
      bar.cut();
    }

    // MyStaticClass.staticCall() is not a seam because I cannot replace
    // staticCall() with different behavior without calling a class besides
    // MyStaticClass, or changing the code in MyStaticClass.
    MyStaticClass.staticCall();

    // This is not a seam either because I can't change the behavior of what
    // happens when instanceCall() occurs with out changing this method or
    // the code in instanceCall().
    (new MyInstanceClass()).instanceCall();
  }
}

Les coutures illustrées ci-dessus seraient des coutures à moins que:

1. La classe injectée est définitive.
2. La méthode appelée est définitive.

Fondamentalement, les coutures facilitent les tests unitaires. Je ne peux pas écrire de test unitaire à MyClasscause des appels vers MyStaticClass.staticCall()et (new MyInstanceClass()).instanceCall(). Tout test unitaire pour MyClassdes » doBunchOfStuff()méthode aurait à tester MyStaticClass.staticCall()et (new MyInstanceClass()).instanceCall()et toutes leurs dépendances qui s'appelle. Inversement, en utilisant des classes non finales avec des méthodes non finales (ou mieux encore - des interfaces), les instances injectées de Fooet BarFactoryrendent MyClasspossible des tests unitaires pour écrire en facilitant la simulation.