Masalah dengan memahami kata "jahitan"

Saya membaca "Ketergantungan Injeksi dalam. NET" oleh Mark Seemann (ini fantastis, dan harus dimiliki) dan penulis sering menggunakan kata "jahitan". Tetapi saya tidak mengerti apa artinya itu. Berikut ini contoh penggunaan kata ini:

Bab 7 menjelaskan cara menyusun objek dalam berbagai kerangka kerja konkret seperti ASP.NET MVC, WPF, WCF, dan sebagainya. Tidak semua kerangka mendukung DI sama baiknya, dan bahkan di antara mereka yang melakukannya, cara mereka melakukannya sangat berbeda. Untuk setiap kerangka kerja, mungkin sulit untuk mengidentifikasi SEAM yang memungkinkan DI dalam kerangka kerja itu. Namun, begitu SEAM ditemukan, Anda memiliki solusi untuk semua aplikasi yang menggunakan kerangka kerja khusus ini. Dalam bab 7, saya telah melakukan pekerjaan ini untuk kerangka kerja aplikasi .NET yang paling umum. Anggap saja sebagai katalog kerangka SEAMS.

Saya akan berterima kasih karena membantu saya memahami kata ini.

Saya pikir istilah ini berasal dari Michael Feathers Bekerja Efektif dengan Kode Legacy di mana ia menjelaskan lapisan dalam perangkat lunak sebagai tempat di mana dua bagian dari perangkat lunak bertemu dan di mana sesuatu yang lain dapat disuntikkan. Analoginya adalah jahitan dalam pakaian: Tempat di mana dua bagian dijahit menjadi satu. Potongan di setiap sisi hanya menyentuh yang lain tepat di jahitan. Kembali ke perangkat lunak: Jika Anda mengidentifikasi jahitan, Anda telah mengidentifikasi tempat di mana ada antarmuka yang terdefinisi dengan baik. Itulah yang dapat Anda manfaatkan dalam DI, karena antarmuka seperti itu memungkinkan Anda untuk mengganti implementasi tanpa perangkat lunak lainnya dapat mengetahui (tanpa curang, bagaimanapun juga).

Berdasarkan jawaban Christian, setahu saya, istilah jahitan memang berasal dari buku Feathers, Bekerja Efektif dengan Legacy Code . Definisi ada di halaman 31:

Jahitan adalah tempat di mana Anda dapat mengubah perilaku di program Anda tanpa mengedit di tempat itu.

Untuk memberikan contoh apa itu jahitan dan apa yang bukan, pertimbangkan kode Java berikut:

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

Jahitan yang dicontohkan di atas adalah jahitan kecuali:

1. Kelas yang disuntikkan adalah final.
2. Metode yang dipanggil adalah final.

Pada dasarnya, jahitan memudahkan pengujian unit. Saya tidak dapat menulis unit test MyClasskarena panggilan ke MyStaticClass.staticCall()dan (new MyInstanceClass()).instanceCall(). Setiap unit test untuk MyClass's doBunchOfStuff()metode harus tes MyStaticClass.staticCall()dan (new MyInstanceClass()).instanceCall()dan semua dependensi mereka yang dipanggil. Sebaliknya, dengan menggunakan kelas-kelas non-final dengan metode-metode non-final (atau antarmuka yang lebih baik lagi), contoh-contoh yang disuntikkan dari Foodan BarFactorymembuat unit test untuk MyClassmemungkinkan untuk menulis dengan memfasilitasi mengejek.