Vấn đề với sự hiểu biết từ đường may

Tôi đang đọc "Dependency Injection in .NET" của Mark Seemann (thật tuyệt vời và phải có) và tác giả thường sử dụng từ "đường may". Nhưng tôi không thể hiểu ý nghĩa của nó. Đây là một ví dụ về việc sử dụng từ này:

Chương 7 giải thích cách soạn thảo các đối tượng trong các khung cụ thể khác nhau như ASP.NET MVC, WPF, WCF, v.v. Không phải tất cả các khung đều hỗ trợ DI tốt như nhau, và ngay cả trong số các khung đó, cách chúng thực hiện khác nhau rất nhiều. Đối với mỗi khung, có thể khó xác định SEAM cho phép DI trong khung đó. Tuy nhiên, một khi SEAM được tìm thấy, bạn có một giải pháp cho tất cả các ứng dụng sử dụng khung cụ thể này. Trong chương 7, tôi đã thực hiện công việc này cho các khung ứng dụng .NET phổ biến nhất. Hãy nghĩ về nó như là một danh mục của khung SEams.

Tôi sẽ rất vui vì đã giúp tôi hiểu từ này.

Tôi nghĩ thuật ngữ này bắt nguồn từ Michael Feathers Hoạt động hiệu quả với Legacy Code, trong đó ông giải thích một đường nối trong phần mềm là nơi hai phần mềm gặp nhau và nơi có thể tiêm thứ gì khác. Sự tương tự là một đường may trong quần áo: Nơi hai phần được khâu lại với nhau. Các mảnh ở mỗi bên chỉ chạm vào bên phải ở đường may. Quay lại phần mềm: Nếu bạn xác định đường may bạn đã xác định được nơi có giao diện được xác định rõ. Đó là những gì bạn có thể tận dụng trong DI, vì giao diện như vậy cho phép bạn thay thế việc thực hiện mà không cần phần mềm còn lại có thể nói (dù sao cũng không gian lận).

Dựa trên câu trả lời của Christian, theo hiểu biết tốt nhất của tôi, thuật ngữ đường may bắt nguồn từ cuốn sách của Feathers, hoạt động hiệu quả với Bộ luật kế thừa . Định nghĩa nằm ở trang 31:

Đường may là nơi bạn có thể thay đổi hành vi trong chương trình của mình mà không cần chỉnh sửa ở nơi đó.

Để đưa ra các ví dụ về đường may là gì và không phải là gì, hãy xem xét mã Java sau:

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

Các đường nối được minh họa ở trên sẽ là các đường nối trừ khi:

1. Các lớp được tiêm là cuối cùng.
2. Phương pháp đang được gọi là cuối cùng.

Về cơ bản, các đường nối tạo điều kiện cho thử nghiệm đơn vị. Tôi không thể viết bài kiểm tra đơn vị MyClassvì các cuộc gọi đến MyStaticClass.staticCall()và (new MyInstanceClass()).instanceCall(). Bất kỳ thử nghiệm đơn vị cho MyClass's doBunchOfStuff()phương pháp sẽ phải kiểm tra MyStaticClass.staticCall()và (new MyInstanceClass()).instanceCall()và tất cả các phụ thuộc của họ mà có được gọi. Ngược lại, bằng cách sử dụng các lớp không phải là cuối cùng với các phương thức không phải là cuối cùng (hoặc tốt hơn - các giao diện), các thể hiện được đưa vào Foovà BarFactorythực hiện các bài kiểm tra đơn vị để MyClasscó thể viết bằng cách tạo điều kiện cho việc chế nhạo.