Problema con la comprensione della parola "cucitura"

Sto leggendo "Dependency Injection in .NET" di Mark Seemann (è fantastico e deve avere) e l'autore usa spesso la parola "cucitura". Ma non riesco a capire cosa significhi. Ecco un esempio dell'uso di questa parola:

Il capitolo 7 spiega come comporre oggetti in vari framework concreti come ASP.NET MVC, WPF, WCF e così via. Non tutti i framework supportano altrettanto bene DI, e anche tra quelli che lo fanno, i modi in cui lo fanno differiscono molto. Per ciascun framework, può essere difficile identificare il SEAM che abilita DI in quel framework. Tuttavia, una volta trovato SEAM, è disponibile una soluzione per tutte le applicazioni che utilizzano questo particolare framework. Nel capitolo 7, ho svolto questo lavoro per i più comuni framework di applicazioni .NET. Pensalo come un catalogo di SEAMS quadro.

Le sarei grato per avermi aiutato a comprendere questa parola.

Penso che il termine provenga da Michael Feathers che lavora in modo efficace con il codice legacy in cui spiega una cucitura nel software come un luogo in cui due parti del software si incontrano e dove si può iniettare qualcos'altro. L'analogia è una cucitura in abbigliamento: il luogo in cui due parti sono cucite insieme. Il pezzo su ciascun lato tocca solo l'altro diritto sulla cucitura. Torna al software: se identifichi la cucitura hai identificato il luogo in cui esiste un'interfaccia ben definita. Questo è ciò che puoi sfruttare in DI, poiché una tale interfaccia ti consente di sostituire l'implementazione senza che il resto del software sia in grado di dirlo (senza barare, comunque).

Basandomi sulla risposta di Christian, per quanto ne so, il termine cucitura proviene dal libro di Feathers, che lavora efficacemente con il codice legacy . La definizione è a pagina 31:

Una cucitura è un luogo in cui è possibile modificare il comportamento del programma senza modificarlo in quel punto.

Per dare esempi di cosa sia una cucitura e cosa non lo sia, considerare il seguente codice Java:

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();
  }
}

Le cuciture sopra esemplificate sarebbero cuciture a meno che:

1. La classe che viene iniettata è definitiva.
2. Il metodo chiamato è definitivo.

Fondamentalmente, le cuciture facilitano i test unitari. Non riesco a scrivere un test unitario a MyClasscausa delle chiamate a MyStaticClass.staticCall()e (new MyInstanceClass()).instanceCall(). Qualsiasi test di unità per MyClass's doBunchOfStuff()metodo avrebbe dovuto testare MyStaticClass.staticCall()e (new MyInstanceClass()).instanceCall()e tutte le loro dipendenze che vengono chiamati. Viceversa, usando le classi non finali con metodi non finali (o meglio ancora - interfacce), le istanze iniettate Fooe BarFactoryrendono i test unitari MyClasspossibili per scrivere facilitando il derisione.