Problem ze zrozumieniem słowa „szew”

Czytam „Dependency Injection in .NET” Mark Seemann (jest fantastyczny i musi mieć), a autor często używa słowa „szew”. Ale nie rozumiem, co to znaczy. Oto przykład użycia tego słowa:

Rozdział 7 wyjaśnia, jak komponować obiekty w różnych konkretnych ramach, takich jak ASP.NET MVC, WPF, WCF i tak dalej. Nie wszystkie frameworki obsługują DI równie dobrze, a nawet wśród tych, które to robią, sposób, w jaki to robią, bardzo się różni. Dla każdego szkieletu może być trudne zidentyfikowanie SEAM, który umożliwia DI w tych ramach. Jednak po znalezieniu SEAM masz rozwiązanie dla wszystkich aplikacji korzystających z tego konkretnego frameworka. W rozdziale 7 wykonałem tę pracę dla najpopularniejszych platform aplikacji .NET. Pomyśl o tym jak o katalogu SEAMS.

Byłbym wdzięczny za pomoc w zrozumieniu tego słowa.

Myślę, że termin ten pochodzi od Michaela Feathersa, który skutecznie współpracuje ze starszym kodem, w którym wyjaśnia szew w oprogramowaniu jako miejscu, w którym spotykają się dwie części oprogramowania i gdzie można wstrzyknąć coś innego. Analogią jest szew w ubraniu: miejsce, w którym dwie części są ze sobą połączone. Kawałek z każdej strony dotyka tylko prawej strony szwu. Powrót do oprogramowania: Jeśli zidentyfikujesz szew, zidentyfikujesz miejsce, w którym istnieje dobrze zdefiniowany interfejs. To właśnie możesz wykorzystać w DI, ponieważ taki interfejs pozwala zastąpić implementację bez reszty oprogramowania, która jest w stanie powiedzieć (w każdym razie bez oszustwa).

Opierając się na odpowiedzi Christiana, zgodnie z moją najlepszą wiedzą, termin szew pochodzi z książki Feathers, Skutecznie współpracując ze starszym kodeksem . Definicja znajduje się na stronie 31:

Szew to miejsce, w którym możesz zmienić zachowanie w swoim programie bez edycji w tym miejscu.

Aby podać przykłady, czym jest szew, a czym nie jest, rozważ następujący kod 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();
  }
}

Szwy przedstawione powyżej byłyby szwami, chyba że:

1. Wstrzykiwana klasa jest ostateczna.
2. Wywoływana metoda jest ostateczna.

Zasadniczo szwy ułatwiają testowanie jednostkowe. Nie mogę napisać testu jednostkowego dla MyClassze względu na połączenia do MyStaticClass.staticCall()i (new MyInstanceClass()).instanceCall(). Wszelkie testy jednostkowe dla MyClass„s doBunchOfStuff()metodą musiałby testu MyStaticClass.staticCall()i (new MyInstanceClass()).instanceCall()i wszyscy ich zależnościami, które się nazywa. I odwrotnie, poprzez zastosowanie niefinałowych klas z niekończącymi się metodami (lub jeszcze lepiej - interfejsami), wstrzykiwane instancje Fooi BarFactorytesty jednostkowe są MyClassmożliwe do napisania przez ułatwienie kpiny.