Thuật ngữ kỹ thuật để biểu thị ngược lại với tiêm phụ thuộc?

Đây là nhiều hơn một danh pháp (viết kỹ thuật) chứ không phải là một câu hỏi thuần túy kỹ thuật. Tôi đang cố gắng viết một đề xuất tái cấu trúc (và được chỉ định cho chính mình) tập trung vào việc mở rộng tiêm phụ thuộc trong ứng dụng của chúng tôi. Mặc dù chúng tôi sử dụng Spring để tự động đậu, nhưng vẫn có những trường hợp khởi tạo đậu bằng cách sử dụng MyClass obj = new MyClass(...), hoàn toàn có thể được tiêm. Tôi muốn làm cho đề xuất của tôi sử dụng danh pháp thanh lịch và tham khảo mẫu thiết kế đối lập với DI với một thuật ngữ thích hợp.

"Khớp nối chặt chẽ" có phải là một thuật ngữ thích hợp có nghĩa là từ trái nghĩa với DI không?

Không. Khớp nối chặt chẽ hơn nhiều so với những gì liên quan đến tiêm chích phụ thuộc.

Phụ thuộc tiêm bên ngoài một quyết định thực hiện. Điều này đi một chặng đường dài để tách rời nhưng khớp nối không chỉ là điều này.

Một từ trái nghĩa tốt cho tiêm phụ thuộc là mã hóa cứng một phụ thuộc . Khi bạn xây dựng (sử dụng mới hoặc trực tiếp sử dụng một số nhà máy) bên trong một đối tượng hành vi, bạn đã làm mờ đi hai mối quan tâm khác nhau. Trình định vị dịch vụ giúp tách rời nhưng để bạn kết hợp với trình định vị dịch vụ.

Khớp nối không chỉ là phân tách xây dựng và hành vi. Nếu tôi có 101 phương thức phải được gọi theo một số thứ tự cụ thể từ lớp A đến lớp B, tôi sẽ liên kết chặt chẽ. Không quan trọng việc xây dựng và hành vi được phân tách tuyệt vời như thế nào.

Khớp nối là thước đo sự phụ thuộc lẫn nhau của hai đối tượng. Bất cứ điều gì góp phần làm cho khó thực hiện thay đổi trong một mà không ảnh hưởng đến cái khác là góp phần vào khớp nối. Phụ thuộc tiêm giúp với điều này nhưng nó không phải là tất cả.

Nói một cách chính xác, Dependency Injection chỉ thực sự phản đối KHÔNG phụ thuộc vào tiêm chích - và do đó, bất kỳ chiến lược quản lý phụ thuộc nào không phải là Dependency Injection.

Khớp nối [không mong muốn], mặc dù không chính xác là một vấn đề trực giao, có thể xảy ra hoặc được giảm nhẹ theo một trong hai cách. Cả hai đều được kết hợp với DependencyClass:

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorđược kết hợp với một cụ thể DependencyClasstrong trường hợp này. Nhưng, cả hai đều được ghép nối với DependencyClass. Tội ác thực sự, nếu có một ở đây, không nhất thiết phải là khớp nối, nó DependencyLookupConstructorcần phải thay đổi nếu DependencyClassđột nhiên cần sự phụ thuộc của chính nó vào ¹ .

Tuy nhiên, hàm tạo / lớp này thậm chí còn được ghép lỏng lẻo hơn :

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

Nếu bạn đang làm việc trong C #, những điều trên sẽ cho phép bạn ServiceLocatortrả lại bất cứ thứ gì khi GetMyDoer()được gọi, miễn là nó có thể có do()những gì DependencyLocatingConstructorcó do(). Bạn nhận được lợi ích của xác thực chữ ký thời gian biên dịch mà thậm chí không được ghép nối với giao diện hoàn chỉnh ² .

Vì vậy, chọn chất độc của bạn.

Nhưng về cơ bản, nếu có một "đối nghịch" cụ thể của Dependency Injection, thì đó sẽ là một thứ khác trong lĩnh vực "Chiến lược quản lý phụ thuộc". Trong số những người khác, nếu bạn đã sử dụng bất kỳ điều nào sau đây trong cuộc trò chuyện, tôi sẽ nhận ra đó là việc KHÔNG phụ thuộc vào tiêm:

• Mẫu định vị dịch vụ
• Định vị phụ thuộc / Địa điểm
• Đối tượng trực tiếp / phụ thuộc xây dựng
• Phụ thuộc ẩn
• "Không phụ thuộc tiêm"

^{1. Trớ trêu thay, một số vấn đề mà DI giải quyết ở các cấp cao hơn là kết quả của việc [sử dụng quá mức] khi sử dụng DI ở các cấp thấp hơn. Tôi đã có những niềm vui của làm việc trên codebases với độ phức tạp không cần thiết trên khắp như là kết quả của sức chứa số ít các nơi phức tạp mà thực sự giúp ... Tôi phải thừa nhận là thiên vị do tiếp xúc xấu.}

^{2. Sử dụng vị trí dịch vụ cũng cho phép bạn dễ dàng chỉ định các phụ thuộc khác nhau cùng loại theo vai trò chức năng của chúng từ mã gọi , trong khi vẫn không rõ ràng về cách thức phụ thuộc được xây dựng. Giả sử bạn cần giải quyết Userhoặc IUsercho các mục đích khác nhau: Ví dụ, Locator.GetAdministrator()so với Locator.GetAuthor()- hoặc bất cứ điều gì. Mã của tôi có thể yêu cầu những gì nó cần về chức năng mà không cần biết nó hỗ trợ giao diện nào.}

Tôi không biết rằng có cụ thể, thuật ngữ ngành công nghiệp chấp nhận rộng rãi, nhưng lựa chọn thay thế mà tôi suy nghĩ bao gồm việc tạo ra nội dụ , tạo ra sự phụ thuộc nội bộ , phụ thuộc ở địa phương , hoặc phụ thuộc scoped tại địa phương .

Tôi sẽ đi với đóng gói phụ thuộc . Điều này thể hiện sự phụ thuộc bị khóa thay vì truy cập và rời đi một lần nữa.