Problema ao entender a palavra "costura"

Estou lendo "Injeção de Dependências no .NET", de Mark Seemann (é fantástico e deve ter) e o autor costuma usar a palavra "costura". Mas não consigo entender o que isso significa. Aqui está um exemplo do uso desta palavra:

O capítulo 7 explica como compor objetos em várias estruturas concretas, como ASP.NET MVC, WPF, WCF e assim por diante. Nem todas as estruturas suportam o DI igualmente bem, e mesmo entre aqueles que o fazem, a maneira como o fazem é muito diferente. Para cada estrutura, pode ser difícil identificar o SEAM que habilita a DI nessa estrutura. No entanto, uma vez encontrado o SEAM, você terá uma solução para todos os aplicativos que usam essa estrutura específica. No capítulo 7, eu fiz esse trabalho para as estruturas de aplicativos .NET mais comuns. Pense nisso como um catálogo de estruturas SEAMS.

Eu ficaria agradecido por me ajudar a entender essa palavra.

Eu acho que o termo se origina de Michael Feathers Working Effective with Legacy Code, no qual ele explica uma emenda no software como um local onde duas partes do software se encontram e onde outra coisa pode ser injetada. A analogia é uma costura na roupa: o local onde duas partes são costuradas. A peça de cada lado só toca a outra à direita na costura. Voltar ao software: Se você identificar a costura, identificou o local em que há uma interface bem definida. É isso que você pode aproveitar no DI, pois essa interface permite substituir a implementação sem que o restante do software saiba (sem trapacear, de qualquer maneira).

Com base na resposta de Christian, até onde sei, o termo costura se origina do livro de Feathers, Working Effective with Legacy Code . A definição está na página 31:

Uma costura é um local onde você pode alterar o comportamento do seu programa sem editar nesse local.

Para dar exemplos do que é e do que não é uma costura, considere o seguinte código 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();
  }
}

As costuras exemplificadas acima seriam costuras, a menos que:

1. A aula que está sendo injetada é final.
2. O método que está sendo chamado é final.

Basicamente, as costuras facilitam o teste de unidade. Não consigo escrever um teste de unidade MyClassdevido às chamadas para MyStaticClass.staticCall()e (new MyInstanceClass()).instanceCall(). Qualquer teste de unidade para MyClass's doBunchOfStuff()método teria de teste MyStaticClass.staticCall()e (new MyInstanceClass()).instanceCall()e tudo de suas dependências que são chamados. Por outro lado, usando classes não finais com métodos não finais (ou melhor ainda - interfaces), as instâncias injetadas Fooe BarFactorytornam MyClasspossíveis testes de unidade para escrever, facilitando a zombaria.