Chỉ trích và nhược điểm của tiêm phụ thuộc

Phụ thuộc tiêm (DI) là một mô hình nổi tiếng và thời trang. Hầu hết các kỹ sư biết lợi thế của nó, như:

• Làm cho sự cô lập trong kiểm tra đơn vị có thể / dễ dàng
• Xác định rõ ràng sự phụ thuộc của một lớp
• Tạo điều kiện thiết kế tốt ( ví dụ nguyên tắc trách nhiệm (SRP))
• Cho phép thực hiện chuyển đổi nhanh chóng ( DbLoggerthay vì ConsoleLoggerví dụ)

Tôi cho rằng có sự đồng thuận rộng rãi trong ngành rằng DI là một mô hình tốt, hữu ích. Không có quá nhiều chỉ trích vào lúc này. Nhược điểm được đề cập trong cộng đồng thường là nhỏ. Vài người trong số họ:

• Số lượng lớp học tăng lên
• Tạo các giao diện không cần thiết

Hiện tại chúng tôi thảo luận về thiết kế kiến ​​trúc với đồng nghiệp của tôi. Anh ấy khá bảo thủ, nhưng cởi mở. Anh ấy thích đặt câu hỏi, điều mà tôi cho là tốt, bởi vì nhiều người trong ngành CNTT chỉ sao chép xu hướng mới nhất, lặp lại những lợi thế và nói chung đừng suy nghĩ quá nhiều - đừng phân tích quá sâu.

Những điều tôi muốn hỏi là:

• Chúng ta có nên sử dụng tiêm phụ thuộc khi chúng ta chỉ có một thực hiện?
• Chúng ta có nên cấm tạo các đối tượng mới ngoại trừ các đối tượng ngôn ngữ / khung không?
• Có phải việc đưa ra một ý tưởng thực hiện xấu (giả sử chúng ta chỉ có một triển khai nên chúng ta không muốn tạo giao diện "trống") nếu chúng ta không có kế hoạch kiểm tra đơn vị một lớp cụ thể?

Đầu tiên, tôi muốn tách biệt phương pháp thiết kế khỏi khái niệm khung. Tiêm phụ thuộc ở cấp độ đơn giản và cơ bản nhất của nó chỉ đơn giản là:

Một đối tượng cha cung cấp tất cả các phụ thuộc cần thiết cho đối tượng con.

Đó là nó. Lưu ý rằng không có gì trong đó yêu cầu giao diện, khung, bất kỳ kiểu tiêm nào, v.v. Để công bằng, lần đầu tiên tôi đã tìm hiểu về mẫu này 20 năm trước. Nó không phải là mới.

Do có hơn 2 người nhầm lẫn giữa thuật ngữ cha mẹ và con cái, trong bối cảnh tiêm phụ thuộc:

• Các mẹ là đối tượng mà instantiates và cấu hình các đối tượng trẻ em nó sử dụng
• Các con là thành phần được thiết kế để được khởi tạo một cách thụ động. Tức là nó được thiết kế để sử dụng bất kỳ phụ thuộc nào được cung cấp bởi cha mẹ và không khởi tạo các phụ thuộc của chính nó.

Phụ thuộc tiêm là một mô hình cho thành phần đối tượng .

Tại sao giao diện?

Giao diện là một hợp đồng. Chúng tồn tại để hạn chế mức độ kết hợp chặt chẽ giữa hai đối tượng. Không phải mọi phụ thuộc đều cần một giao diện, nhưng chúng giúp viết mã mô-đun.

Khi bạn thêm vào khái niệm kiểm thử đơn vị, bạn có thể có hai triển khai khái niệm cho bất kỳ giao diện cụ thể nào: đối tượng thực bạn muốn sử dụng trong ứng dụng của mình và đối tượng bị nhạo báng hoặc sơ khai mà bạn sử dụng để kiểm tra mã phụ thuộc vào đối tượng. Điều đó một mình có thể đủ biện minh cho giao diện.

Tại sao khung?

Về cơ bản, việc khởi tạo và cung cấp các phụ thuộc cho các đối tượng con có thể gây nản chí khi có một số lượng lớn chúng. Các khung cung cấp các lợi ích sau:

• Tự động phụ thuộc vào các thành phần
• Cấu hình các thành phần với các thiết lập của một số loại
• Tự động hóa mã tấm nồi hơi để bạn không phải nhìn thấy nó được viết ở nhiều vị trí.

Họ cũng có những nhược điểm sau:

• Đối tượng cha là một "thùng chứa" và không có gì trong mã của bạn
• Nó làm cho việc kiểm tra trở nên phức tạp hơn nếu bạn không thể cung cấp các phụ thuộc trực tiếp trong mã kiểm tra của mình
• Nó có thể làm chậm quá trình khởi tạo vì nó giải quyết tất cả các phụ thuộc bằng cách sử dụng sự phản chiếu và nhiều thủ thuật khác
• Việc gỡ lỗi thời gian chạy có thể khó khăn hơn, đặc biệt nếu container chứa proxy giữa giao diện và thành phần thực tế thực hiện giao diện (lập trình hướng theo khía cạnh được tích hợp trong Spring). Hộp chứa là một hộp đen và chúng không phải luôn được chế tạo với bất kỳ khái niệm nào tạo thuận lợi cho quá trình gỡ lỗi.

Tất cả những gì đã nói, có sự đánh đổi. Đối với các dự án nhỏ, nơi không có nhiều bộ phận chuyển động và có ít lý do để sử dụng khung DI. Tuy nhiên, đối với các dự án phức tạp hơn, nơi đã có một số thành phần nhất định được thực hiện cho bạn, khung có thể được biện minh.

Còn [bài viết ngẫu nhiên trên Internet] thì sao?

Còn nó thì sao? Nhiều lần mọi người có thể trở nên quá nhiệt tình và thêm một loạt các hạn chế và đánh cược bạn nếu bạn không làm mọi thứ theo "một cách thực sự". Không có một cách đúng. Xem nếu bạn có thể trích xuất bất cứ điều gì hữu ích từ bài viết và bỏ qua những thứ bạn không đồng ý.

Tóm lại, hãy suy nghĩ cho bản thân và thử mọi thứ.

Làm việc với "những cái đầu cũ"

Tìm hiểu càng nhiều càng tốt. Những gì bạn sẽ tìm thấy với rất nhiều nhà phát triển đang làm việc ở độ tuổi 70 là họ đã học được cách không giáo điều về rất nhiều thứ. Họ có những phương pháp mà họ đã làm việc trong nhiều thập kỷ để tạo ra kết quả chính xác.

Tôi đã có đặc quyền làm việc với một vài trong số này, và họ có thể cung cấp một số phản hồi trung thực một cách tàn nhẫn có nhiều ý nghĩa. Và nơi họ thấy giá trị, họ thêm những công cụ đó vào tiết mục của mình.

Tiêm phụ thuộc, giống như hầu hết các mẫu, là một giải pháp cho các vấn đề . Vì vậy, bắt đầu bằng cách hỏi nếu bạn thậm chí có vấn đề ở nơi đầu tiên. Nếu không, sau đó sử dụng mẫu rất có thể sẽ làm cho mã tồi tệ hơn .

Hãy xem xét đầu tiên nếu bạn có thể giảm hoặc loại bỏ sự phụ thuộc. Tất cả những thứ khác đều bằng nhau, chúng tôi muốn mỗi thành phần trong một hệ thống có càng ít phụ thuộc càng tốt. Và nếu sự phụ thuộc không còn nữa, câu hỏi tiêm hay không trở thành tranh luận!

Xem xét một mô-đun tải xuống một số dữ liệu từ một dịch vụ bên ngoài, phân tích cú pháp và thực hiện một số phân tích phức tạp và ghi vào kết quả vào một tệp.

Bây giờ, nếu sự phụ thuộc vào dịch vụ bên ngoài được mã hóa cứng, thì sẽ rất khó để kiểm tra đơn vị xử lý nội bộ của mô-đun này. Vì vậy, bạn có thể quyết định tiêm dịch vụ bên ngoài và hệ thống tệp dưới dạng phụ thuộc giao diện, điều này sẽ cho phép bạn tiêm giả thay vào đó, điều này giúp kiểm tra đơn vị logic bên trong có thể.

Nhưng một giải pháp tốt hơn nhiều chỉ đơn giản là tách phân tích khỏi đầu vào / đầu ra. Nếu phân tích được trích xuất thành một mô-đun mà không có tác dụng phụ, nó sẽ dễ dàng hơn để kiểm tra. Lưu ý rằng chế nhạo là một mùi mã - không phải lúc nào cũng có thể tránh được, nhưng nói chung, sẽ tốt hơn nếu bạn có thể kiểm tra mà không cần dựa vào chế độ chế nhạo. Vì vậy, bằng cách loại bỏ các phụ thuộc, bạn tránh được các vấn đề mà DI được cho là sẽ giảm bớt. Lưu ý rằng thiết kế như vậy cũng tuân thủ SRP tốt hơn nhiều.

Tôi muốn nhấn mạnh rằng DI không nhất thiết tạo điều kiện thuận lợi cho SRP hoặc các nguyên tắc thiết kế tốt khác như tách biệt mối quan tâm, độ gắn kết cao / khớp nối thấp, v.v. Nó cũng có thể có tác dụng ngược lại. Hãy xem xét một lớp A sử dụng một lớp B khác trong nội bộ. B chỉ được sử dụng bởi A và do đó được đóng gói đầy đủ và có thể được coi là một chi tiết thực hiện. Nếu bạn thay đổi điều này để tiêm B vào hàm tạo của A, thì bạn đã tiết lộ chi tiết triển khai này và bây giờ có kiến ​​thức về sự phụ thuộc này và về cách khởi tạo B, thời gian tồn tại của B và phải tồn tại một vị trí khác trong hệ thống từ A. Vì vậy, bạn có một kiến ​​trúc tổng thể tồi tệ hơn với những lo ngại rò rỉ.

Mặt khác, có một số trường hợp DI thực sự hữu ích. Ví dụ cho các dịch vụ toàn cầu với các tác dụng phụ như logger.

Vấn đề là khi các mẫu và kiến ​​trúc trở thành mục tiêu trong chính chúng chứ không phải là công cụ. Chỉ cần hỏi "Chúng ta có nên sử dụng DI?" là loại đặt xe trước ngựa. Bạn nên hỏi: "Chúng ta có vấn đề à?" và "giải pháp tốt nhất cho vấn đề này là gì?"

Một phần câu hỏi của bạn tập trung vào: "Chúng ta có nên tạo giao diện thừa để đáp ứng nhu cầu của mẫu không?" Bạn có thể đã nhận ra câu trả lời cho điều này - hoàn toàn không ! Bất cứ ai nói với bạn nếu không đang cố gắng bán cho bạn một cái gì đó - rất có thể là giờ tư vấn đắt tiền. Một giao diện chỉ có giá trị nếu nó đại diện cho một sự trừu tượng. Một giao diện chỉ bắt chước bề mặt của một lớp duy nhất được gọi là "giao diện tiêu đề" và đây là một phản mẫu đã biết.

Theo kinh nghiệm của tôi, có một số nhược điểm đối với việc tiêm phụ thuộc.

Đầu tiên, sử dụng DI không đơn giản hóa việc kiểm tra tự động nhiều như quảng cáo. Đơn vị kiểm tra một lớp với việc thực hiện giao diện giả cho phép bạn xác thực cách lớp đó sẽ tương tác với giao diện. Đó là, nó cho phép bạn kiểm tra đơn vị cách lớp đang kiểm tra sử dụng hợp đồng được cung cấp bởi giao diện. Tuy nhiên, điều này cung cấp sự đảm bảo lớn hơn nhiều rằng đầu vào từ lớp được kiểm tra vào giao diện như mong đợi. Nó cung cấp sự đảm bảo khá kém rằng lớp được kiểm tra đáp ứng như mong đợi để xuất ra từ giao diện vì đó là đầu ra giả gần như toàn cầu, bản thân nó có lỗi, quá đơn giản, v.v. Nói tóm lại, nó KHÔNG cho phép bạn xác nhận rằng lớp sẽ hoạt động như mong đợi với việc triển khai thực sự giao diện.

Thứ hai, DI làm cho việc điều hướng qua mã khó khăn hơn nhiều. Khi cố gắng điều hướng đến định nghĩa của các lớp được sử dụng làm đầu vào cho các hàm, giao diện có thể là bất cứ điều gì từ một sự phiền toái nhỏ (ví dụ khi có một triển khai duy nhất) đến một khoảng thời gian chính (ví dụ: khi sử dụng giao diện quá chung chung như IDis Dùng) khi cố gắng tìm việc thực hiện đang được sử dụng. Điều này có thể biến một bài tập đơn giản như "Tôi cần sửa một ngoại lệ tham chiếu null trong mã xảy ra ngay sau khi câu lệnh ghi nhật ký này được in" thành một nỗ lực dài cả ngày.

Thứ ba, việc sử dụng DI và khung là con dao hai lưỡi. Nó có thể làm giảm đáng kể số lượng mã nồi hơi cần thiết cho các hoạt động chung. Tuy nhiên, điều này phải trả giá khi cần có kiến ​​thức chi tiết về khung DI cụ thể để hiểu làm thế nào các hoạt động chung này thực sự được nối với nhau. Hiểu cách phụ thuộc được tải vào khung và thêm một phụ thuộc mới vào khung để tiêm có thể yêu cầu đọc một số lượng lớn tài liệu nền và làm theo một số hướng dẫn cơ bản về khung. Điều này có thể biến một số nhiệm vụ đơn giản thành những việc khá tốn thời gian.

Tôi đã làm theo lời khuyên của Mark Seemann từ "Dependency tiêm trong .NET" - để phỏng đoán.

DI nên được sử dụng khi bạn có 'sự phụ thuộc dễ bay hơi', ví dụ như có khả năng hợp lý nó có thể thay đổi.

Vì vậy, nếu bạn nghĩ rằng bạn có thể có nhiều hơn một triển khai trong tương lai hoặc việc triển khai có thể thay đổi, hãy sử dụng DI. Nếu không thì newtốt.

Thú cưng lớn nhất của tôi về DI đã được đề cập trong một vài câu trả lời theo cách thông qua, nhưng tôi sẽ mở rộng về nó một chút ở đây. DI (vì nó hầu hết được thực hiện ngày hôm nay, với các thùng chứa, v.v.) thực sự, THỰC SỰ làm tổn thương khả năng đọc mã. Và khả năng đọc mã được cho là lý do đằng sau hầu hết các đổi mới lập trình ngày nay. Như ai đó đã nói - viết mã rất dễ dàng. Đọc mã là khó. Nhưng nó cũng cực kỳ quan trọng, trừ khi bạn đang viết một loại tiện ích vứt đi một lần nhỏ xíu.

Vấn đề với DI về vấn đề này là nó mờ đục. Hộp đựng là một hộp đen. Các đối tượng chỉ đơn giản xuất hiện từ đâu đó và bạn không biết - ai đã xây dựng chúng và khi nào? Những gì đã được chuyển đến các nhà xây dựng? Tôi đang chia sẻ trường hợp này với ai? Ai biết...

Và khi bạn làm việc chủ yếu với các giao diện, tất cả các tính năng "đi đến định nghĩa" của IDE của bạn sẽ tan thành mây khói. Thật khó khăn để tìm ra dòng chảy của chương trình mà không chạy nó và chỉ cần bước qua để xem việc triển khai giao diện đã được sử dụng ở vị trí cụ thể NÀY. Và đôi khi có một số trở ngại kỹ thuật ngăn cản bạn bước qua. Và ngay cả khi bạn có thể, nếu nó liên quan đến việc đi qua các cung xoắn của container DI, toàn bộ sự việc nhanh chóng trở thành một bài tập trong sự thất vọng.

Để làm việc hiệu quả với một đoạn mã đã sử dụng DI, bạn phải làm quen với nó và đã biết những gì đi đâu.

Kích hoạt triển khai chuyển đổi nhanh chóng (ví dụ DbLogger thay vì ConsoleLogger)

Mặc dù DI nói chung chắc chắn là một điều tốt, tôi khuyên bạn không nên sử dụng nó một cách mù quáng cho mọi thứ. Ví dụ, tôi không bao giờ tiêm loggers. Một trong những lợi thế của DI là làm cho các phụ thuộc rõ ràng và rõ ràng. Không có điểm nào trong danh sách ILoggerlà sự phụ thuộc của gần như mọi lớp - đó chỉ là sự lộn xộn. Trách nhiệm của logger là cung cấp sự linh hoạt mà bạn cần. Tất cả các logger của tôi là thành viên tĩnh cuối cùng, tôi có thể xem xét việc tiêm logger khi tôi cần một logger không tĩnh.

Số lượng lớp học tăng lên

Đây là một bất lợi của khung DI hoặc khung mô phỏng đã cho, không phải của chính DI. Ở hầu hết các nơi, các lớp học của tôi phụ thuộc vào các lớp cụ thể, điều đó có nghĩa là không cần nồi hơi. Guice (khung công tác Java DI) liên kết theo mặc định một lớp với chính nó và tôi chỉ cần ghi đè liên kết trong các bài kiểm tra (hoặc thay thế chúng bằng tay thay thế).

Tạo các giao diện không cần thiết

Tôi chỉ tạo các giao diện khi cần thiết (điều này khá hiếm). Điều này có nghĩa là đôi khi, tôi phải thay thế tất cả các lần xuất hiện của một lớp bằng một giao diện, nhưng IDE có thể làm điều này cho tôi.

Chúng ta có nên sử dụng tiêm phụ thuộc khi chúng ta chỉ có một thực hiện?

Có, nhưng tránh bất kỳ nồi hơi được thêm vào .

Chúng ta có nên cấm tạo các đối tượng mới ngoại trừ các đối tượng ngôn ngữ / khung không?

Không. Sẽ có nhiều lớp giá trị (không thay đổi) và dữ liệu (có thể thay đổi), trong đó các thể hiện vừa được tạo và chuyển qua và không có điểm nào để tiêm chúng - vì chúng không bao giờ được lưu trữ trong một đối tượng khác (hoặc chỉ trong các đối tượng khác những đối tượng như vậy).

Đối với họ, bạn có thể cần phải tiêm một nhà máy thay thế, nhưng hầu hết thời gian nó không có ý nghĩa gì (hãy tưởng tượng, @Value class NamedUrl {private final String name; private final URL url;}bạn thực sự không cần một nhà máy ở đây và không có gì để tiêm).

Có phải việc đưa ra một ý tưởng thực hiện xấu (giả sử chúng ta chỉ có một triển khai nên chúng ta không muốn tạo giao diện "trống") nếu chúng ta không có kế hoạch kiểm tra đơn vị một lớp cụ thể?

IMHO nó ổn miễn là nó không gây ra sự phình to mã. Đừng phụ thuộc nhưng không tạo giao diện (và không có cấu hình XML điên rồ!) Vì bạn có thể làm điều đó sau mà không gặp rắc rối nào.

Trên thực tế, trong dự án hiện tại của tôi, có bốn lớp (trong số hàng trăm), tôi quyết định loại trừ khỏi DI vì chúng là các lớp đơn giản được sử dụng ở quá nhiều nơi, bao gồm các đối tượng dữ liệu.

Một nhược điểm khác của hầu hết các khung DI là chi phí thời gian chạy. Điều này có thể được chuyển sang thời gian biên dịch (đối với Java, có Dagger , không biết gì về các ngôn ngữ khác).

Tuy nhiên, một nhược điểm khác là phép thuật xảy ra ở mọi nơi, có thể được điều chỉnh (ví dụ: tôi đã vô hiệu hóa việc tạo proxy khi sử dụng Guice).

Tôi phải nói rằng theo ý kiến ​​của tôi, toàn bộ khái niệm về Dependency Injection được đánh giá cao.

DI là ngày hiện đại tương đương với các giá trị toàn cầu. Những thứ bạn đang tiêm là các singletons toàn cầu và các đối tượng mã thuần túy, nếu không, bạn không thể tiêm chúng. Hầu hết việc sử dụng DI đều bắt buộc bạn phải sử dụng một thư viện nhất định (JPA, Spring Data, v.v.). Đối với hầu hết các phần, DI cung cấp môi trường hoàn hảo để nuôi dưỡng và nuôi dưỡng spaghetti.

Thành thật mà nói, cách dễ nhất để kiểm tra một lớp là đảm bảo rằng tất cả các phụ thuộc được tạo trong một phương thức có thể được ghi đè. Sau đó tạo một lớp Test xuất phát từ lớp thực tế và ghi đè phương thức đó.

Sau đó, bạn khởi tạo lớp Test và kiểm tra tất cả các phương thức của nó. Điều này sẽ không rõ ràng đối với một số bạn - các phương pháp bạn đang kiểm tra là những phương pháp thuộc về lớp đang thử nghiệm. Và tất cả các thử nghiệm phương thức này xảy ra trong một tệp lớp duy nhất - lớp thử nghiệm đơn vị được liên kết với lớp được thử nghiệm. Không có chi phí nào ở đây - đây là cách thử nghiệm đơn vị hoạt động.

Trong mã, khái niệm này trông như thế này ...

class ClassUnderTest {

   protected final ADependency;
   protected final AnotherDependency;

   // Call from a factory or use an initializer 
   public void initializeDependencies() {
      aDependency = new ADependency();
      anotherDependency = new AnotherDependency();
   }
}

class TestClassUnderTest extends ClassUnderTest {

    @Override
    public void initializeDependencies() {
      aDependency = new MockitoObject();
      anotherDependency = new MockitoObject();
    }

    // Unit tests go here...
    // Unit tests call base class methods
}

Kết quả hoàn toàn tương đương với việc sử dụng DI - đó là ClassUnderTest được cấu hình để thử nghiệm.

Sự khác biệt duy nhất là mã này hoàn toàn ngắn gọn, được đóng gói hoàn toàn, dễ viết mã hơn, dễ hiểu hơn, nhanh hơn, sử dụng ít bộ nhớ hơn, không yêu cầu cấu hình thay thế, không yêu cầu bất kỳ khung nào, sẽ không bao giờ là nguyên nhân của 4 trang (WTF!) Dấu vết ngăn xếp bao gồm chính xác các lớp ZERO (0) mà bạn đã viết và hoàn toàn rõ ràng đối với bất kỳ ai có kiến ​​thức OO nhỏ nhất, từ người mới bắt đầu đến bậc thầy (bạn sẽ nghĩ, nhưng sẽ bị nhầm lẫn).

Điều đó đang được nói, tất nhiên chúng ta không thể sử dụng nó - nó quá rõ ràng và không đủ hợp thời trang.

Tuy nhiên, vào cuối ngày, mối quan tâm lớn nhất của tôi với DI là các dự án tôi đã thấy thất bại thảm hại, tất cả chúng đều là những cơ sở mã lớn trong đó DI là chất keo giữ mọi thứ lại với nhau. DI không phải là một kiến ​​trúc - nó thực sự chỉ có liên quan trong một số tình huống, hầu hết trong số đó buộc bạn phải sử dụng một thư viện khác (JPA, Spring Data, v.v.). Đối với hầu hết các phần, trong một cơ sở mã được thiết kế tốt, hầu hết việc sử dụng DI sẽ xảy ra ở cấp độ bên dưới nơi diễn ra các hoạt động phát triển hàng ngày của bạn.

Thực sự câu hỏi của bạn sôi sùng sục thành "Thử nghiệm đơn vị có tệ không?"

99% các lớp thay thế của bạn để tiêm sẽ là giả cho phép thử nghiệm đơn vị.

Nếu bạn thực hiện kiểm tra đơn vị mà không có DI, bạn có vấn đề làm thế nào để có được các lớp sử dụng dữ liệu giả định hoặc dịch vụ giả. Hãy nói 'một phần của logic' vì bạn có thể không tách nó ra thành các dịch vụ.

Có nhiều cách khác nhau để làm điều này, nhưng DI là một cách tốt và linh hoạt. Một khi bạn có nó để thử nghiệm, bạn hầu như bị buộc phải sử dụng nó ở mọi nơi, vì bạn cần một số đoạn mã khác, thậm chí nó còn được gọi là 'DI người nghèo', tạo ra các loại cụ thể.

Thật khó để tưởng tượng một nhược điểm tồi tệ đến mức lợi thế của thử nghiệm đơn vị bị áp đảo.