Problema con la comprensión de la palabra "costura"

Estoy leyendo "Inyección de dependencia en .NET" de Mark Seemann (es fantástico, y debe haberlo hecho) y el autor a menudo usa la palabra "costura". Pero no puedo entender lo que significa. Aquí hay un ejemplo del uso de esta palabra:

El Capítulo 7 explica cómo componer objetos en varios marcos concretos como ASP.NET MVC, WPF, WCF, etc. No todos los marcos soportan la DI por igual, e incluso entre aquellos que lo hacen, las formas en que lo hacen difieren mucho. Para cada marco, puede ser difícil identificar el SEAM que permite DI en ese marco. Sin embargo, una vez que se encuentra SEAM, tiene una solución para todas las aplicaciones que utilizan este marco en particular. En el capítulo 7, hice este trabajo para los marcos de aplicaciones .NET más comunes. Piense en ello como un catálogo de marcos SEAMS.

Estaría agradecido por ayudarme a entender esta palabra.

Creo que el término se origina en Michael Feathers Working Effectively with Legacy Code en el que explica una costura en el software como un lugar donde se encuentran dos partes del software y donde se puede inyectar algo más. La analogía es una costura en la ropa: el lugar donde se unen dos partes. La pieza en cada lado solo toca el otro justo en la costura. Volver al software: si identifica la costura, ha identificado el lugar donde hay una interfaz bien definida. Eso es lo que puede aprovechar en DI, ya que dicha interfaz le permite reemplazar la implementación sin que el resto del software pueda distinguir (sin hacer trampa, de todos modos).

Sobre la base de la respuesta de Christian, que yo sepa, el término costura se origina en el libro de Plumas, Trabajando eficazmente con código heredado . La definición está en la página 31:

Una costura es un lugar donde puede alterar el comportamiento en su programa sin editar en ese lugar.

Para dar ejemplos de qué es una costura y qué no es, considere el siguiente 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();
  }
}

Las costuras ejemplificadas anteriormente serían costuras a menos que:

1. La clase que se inyecta es final.
2. El método que se llama es final.

Básicamente, las costuras facilitan las pruebas unitarias. No puedo escribir una prueba unitaria MyClassdebido a las llamadas a MyStaticClass.staticCall()y (new MyInstanceClass()).instanceCall(). Cualquier prueba de la unidad de MyClass's doBunchOfStuff()método tendría que prueba MyStaticClass.staticCall()y (new MyInstanceClass()).instanceCall()y todas sus dependencias que consiguen llama. Por el contrario, al usar clases no finales con métodos no finales (o mejor aún, interfaces), las instancias inyectadas Fooy las BarFactorypruebas unitarias son MyClassposibles de escribir al facilitar la burla.