Problema con la comprensione della parola "cucitura"

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

Basandosi sulla risposta di Christian, per quanto ne so, il termine cucitura deriva dal libro di Piume, funzionante in modo efficace con Codice precedente . La definizione è a pagina 31:

A seam is a place where you can alter behavior in your program without editing in that place.

Per dare esempi di cosa sia una cucitura e cosa non sia, si consideri 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 giunzioni di cui sopra sarebbero cuciture a meno che:

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

Fondamentalmente, le cuciture facilitano il test dell'unità. Non riesco a scrivere un test unitario per MyClass a causa delle chiamate a MyStaticClass.staticCall() e (new MyInstanceClass()).instanceCall() . Qualsiasi test unitario per il MyClass del metodo doBunchOfStuff() dovrebbe testare MyStaticClass.staticCall() e (new MyInstanceClass()).instanceCall() e tutti delle loro dipendenze che vengono richiamati. Viceversa, utilizzando le classi non final con metodi non finali (o, meglio ancora, interfacce), le istanze iniettate di Foo e BarFactory rendono i test unitari per MyClass possibili per scrivere facilitando il mocking.