Проблема с пониманием слова «шов»

Я читаю «Внедрение зависимостей в .NET» Марка Симанна (это фантастика, и обязательно должна иметь), и автор часто использует слово «шов». Но я не могу понять, что это значит. Вот пример использования этого слова:

Глава 7 объясняет, как составлять объекты в различных конкретных средах, таких как ASP.NET MVC, WPF, WCF и так далее. Не все фреймворки одинаково хорошо поддерживают DI, и даже среди тех, кто это делает, способы, которыми они это делают, сильно различаются. Для каждой структуры может быть трудно идентифицировать SEAM, который включает DI в этой структуре. Однако, как только этот SEAM найден, у вас есть решение для всех приложений, которые используют эту конкретную среду. В главе 7 я проделал эту работу для самых распространенных платформ приложений .NET. Думайте об этом как о каталоге каркасов швов.

Я был бы благодарен за помощь в понимании этого слова.

Я думаю, что этот термин происходит от Michael Feathers, эффективно работающего с устаревшим кодом, в котором он объясняет шов в программном обеспечении как место, где встречаются две части программного обеспечения и где можно внедрить что-то еще. Аналогия - шов в одежде: место, где сшиты две части. Часть на каждой стороне касается только другой прямо в шве. Вернемся к программному обеспечению: если вы идентифицировали шов, вы определили место, где есть четко определенный интерфейс. Это то, что вы можете использовать в DI, так как такой интерфейс позволяет вам заменить реализацию без возможности остальной части программного обеспечения (в любом случае, без обмана).

Основываясь на ответе Кристиана, насколько мне известно, термин «шов» происходит из книги Пера «Эффективная работа с устаревшим кодексом» . Определение на странице 31:

Шов - это место, где вы можете изменить поведение в вашей программе без редактирования в этом месте.

Чтобы привести примеры того, что такое шов, а что нет, рассмотрим следующий код 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();
  }
}

Швы, приведенные в качестве примера выше, будут швами, если:

1. Вводимый класс является окончательным.
2. Вызываемый метод является окончательным.

В основном, швы облегчают юнит-тестирование. Я не могу написать модульный тест для MyClassиз-за вызовов MyStaticClass.staticCall()и (new MyInstanceClass()).instanceCall(). Любой тестовый модуль для MyClass«S doBunchOfStuff()метод должен был бы тест MyStaticClass.staticCall()и (new MyInstanceClass()).instanceCall()и все их зависимостей , которые вызываются. И наоборот, используя неконечные классы с не финальными методами (или еще лучше - интерфейсами), внедряются экземпляры Fooи BarFactoryвыполняют модульные тесты для MyClassвозможности написания, облегчая имитацию.