Phần giới thiệu nhanh về Dependency Injection: nó là gì và sử dụng nó khi nào

Giới thiệu

Trong kỹ thuật phần mềm, chèn phụ thuộc là một kỹ thuật theo đó một đối tượng (hoặc phương thức tĩnh) cung cấp các phụ thuộc của đối tượng khác. Một phụ thuộc là một đối tượng có thể được sử dụng (một dịch vụ).

Đó là định nghĩa của Wikipedia, nhưng nó không đặc biệt dễ hiểu. Vì vậy, chúng ta hãy hiểu nó tốt hơn.

Trước khi hiểu ý nghĩa của nó trong lập trình, trước tiên chúng ta hãy xem nó có nghĩa là gì nói chung vì nó sẽ giúp chúng ta hiểu khái niệm tốt hơn.

Phụ thuộc hay phụ thuộc có nghĩa là dựa vào một cái gì đó để được hỗ trợ. Giống như nếu tôi nói rằng chúng ta đang phụ thuộc quá nhiều vào điện thoại di động thì có nghĩa là chúng ta đang phụ thuộc vào chúng.

Vì vậy, trước khi bắt đầu tiêm phụ thuộc , trước tiên hãy hiểu phụ thuộc trong lập trình có nghĩa là gì.

Khi lớp A sử dụng một số chức năng của lớp B, thì lớp A nói rằng lớp A có phụ thuộc của lớp B.

Trong Java, trước khi có thể sử dụng các phương thức của các lớp khác, trước tiên chúng ta cần tạo đối tượng của lớp đó (tức là lớp A cần tạo một thể hiện của lớp B).

Vì vậy, chuyển giao nhiệm vụ tạo đối tượng cho người khác và trực tiếp sử dụng phụ thuộc được gọi là tiêm phụ thuộc.

Tại sao tôi nên sử dụng tiêm phụ thuộc?

Giả sử chúng ta có một lớp ô tô chứa các đối tượng khác nhau như bánh xe, động cơ, v.v.

Ở đây lớp xe chịu trách nhiệm tạo tất cả các đối tượng phụ thuộc. Bây giờ, điều gì sẽ xảy ra nếu chúng ta quyết định từ bỏ MRFWheels trong tương lai và muốn sử dụng Yokohama Wheels?

Chúng ta sẽ cần tạo lại đối tượng xe hơi với một phụ thuộc Yokohama mới. Nhưng khi sử dụng tính năng tiêm phụ thuộc (DI), chúng ta có thể thay đổi Bánh xe trong thời gian chạy (vì các phụ thuộc có thể được tiêm vào thời gian chạy chứ không phải tại thời điểm biên dịch).

Bạn có thể coi DI là người trung gian trong mã của chúng tôi, người thực hiện tất cả công việc tạo đối tượng bánh xe ưa thích và cung cấp nó cho lớp Xe.

Nó làm cho lớp Xe của chúng tôi độc lập với việc tạo ra các đối tượng Bánh xe, Pin, v.v.

Về cơ bản có ba loại tiêm phụ thuộc:

  1. phương thức chèn vào phương thức khởi tạo: các phụ thuộc được cung cấp thông qua một phương thức khởi tạo lớp.
  2. setter injection: khách hàng đưa ra phương pháp setter mà người tiêm sử dụng để tiêm phần phụ thuộc.
  3. tiêm giao diện: phụ thuộc cung cấp một phương thức tiêm sẽ đưa phụ thuộc vào bất kỳ máy khách nào được chuyển đến nó. Khách hàng phải triển khai một giao diện hiển thị một phương thức setter chấp nhận phần phụ thuộc.

Vì vậy, bây giờ trách nhiệm của tiêm phụ thuộc là:

  1. Tạo các đối tượng
  2. Biết lớp nào yêu cầu các đối tượng đó
  3. Và cung cấp cho họ tất cả các đối tượng đó

Nếu có bất kỳ thay đổi nào trong các đối tượng, DI sẽ xem xét nó và nó sẽ không liên quan đến lớp sử dụng các đối tượng đó. Bằng cách này nếu các đối tượng thay đổi trong tương lai, thì DI của nó có trách nhiệm cung cấp các đối tượng thích hợp cho lớp.

Đảo ngược kiểm soát — khái niệm đằng sau DI

Điều này nói rằng một lớp không nên cấu hình tĩnh các phụ thuộc của nó mà nên được cấu hình bởi một số lớp khác từ bên ngoài.

Đó là nguyên tắc thứ năm của SOLID -năm nguyên tắc cơ bản của thiết kế và lập trình hướng đối tượng của Uncle Bob - trong đó nói rằng một lớp nên phụ thuộc vào sự trừu tượng hóa chứ không phụ thuộc vào các cụ thể (nói một cách đơn giản là mã hóa cứng).

Theo các nguyên tắc, một lớp nên tập trung vào việc hoàn thành các trách nhiệm của mình chứ không phải vào việc tạo ra các đối tượng mà nó yêu cầu để hoàn thành các trách nhiệm đó. Và đó là lúc quá trình tiêm phụ thuộc phát huy tác dụng: nó cung cấp cho lớp các đối tượng cần thiết.

Lưu ý: Nếu bạn muốn tìm hiểu về các nguyên tắc SOLID của Uncle Bob thì bạn có thể truy cập liên kết này.

Lợi ích của việc sử dụng DI

  1. Giúp kiểm tra đơn vị.
  2. Mã tấm lò hơi được giảm xuống, vì việc khởi tạo các phụ thuộc được thực hiện bởi thành phần kim phun.
  3. Việc mở rộng ứng dụng trở nên dễ dàng hơn.
  4. Giúp cho phép khớp nối lỏng lẻo, điều quan trọng trong lập trình ứng dụng.

Nhược điểm của DI

  1. Nó hơi phức tạp để tìm hiểu và nếu lạm dụng quá mức có thể dẫn đến các vấn đề quản lý và các vấn đề khác.
  2. Nhiều lỗi thời gian biên dịch được đẩy sang thời gian chạy.
  3. Các khuôn khổ tiêm phụ thuộc được thực hiện với phản xạ hoặc lập trình động. Điều này có thể cản trở việc sử dụng tự động hóa IDE, chẳng hạn như “tìm tài liệu tham khảo”, “hiển thị phân cấp cuộc gọi” và cấu trúc lại an toàn.

Bạn có thể tự mình triển khai quá trình tiêm phụ thuộc (Pure Vanilla) hoặc sử dụng các thư viện hoặc khuôn khổ của bên thứ ba.

Thư viện và khuôn khổ triển khai DI

  • Mùa xuân (Java)
  • Google Guice (Java)
  • Dagger (Java và Android)
  • Castle Windsor (.NET)
  • Unity (.NET)

Để tìm hiểu thêm về việc tiêm phụ thuộc, bạn có thể xem các tài nguyên dưới đây:

Java Dependency Injection - Hướng dẫn ví dụ về mẫu thiết kế DI - JournalDev

Sử dụng phương pháp tiêm phụ thuộc trong Java - Giới thiệu - Hướng dẫn - Vogella

Đảo ngược vùng chứa điều khiển và mẫu tiêm phụ thuộc - Martin Fowler

Hy vọng nó giúp!

Nếu bạn thích bài viết và muốn đọc những bài báo tuyệt vời hơn, hãy theo dõi tôi tại đây (Bhavya Karia) và thể hiện sự ủng hộ của bạn vì nó thúc đẩy tôi viết nhiều hơn.

Nếu bạn có bất kỳ câu hỏi hoặc phản hồi nào cho tôi, hãy kết nối trên LinkedIn, Twitter, Facebook.

Chỉnh sửa 1:

Cảm ơn Sergey Ufocoder bây giờ bài báo này đã được chuyển đổi sang tiếng Nga. Những người bạn Nga của tôi và những người có thể đọc tiếng Nga đều đọc nó.

Liên kết đến bài báo

Ngoài ra, nếu bạn muốn áp dụng DI trong JavaScript và đang tìm kiếm một thư viện thì Jo Surikat khuyên bạn nên thử thư viện của anh ấy.

Di-Ninja

Một thư viện DI tuyệt vời hơn trong JavaScript được đề xuất bởi Nicolas Froidure.

xe đan

Chỉnh sửa 2:

Nếu bạn là một nhà phát triển PHP thì đừng lo lắng, bạn cũng được hỗ trợ hết mình. Gordon Forsythe đã đề xuất thư viện tuyệt vời này mà tất cả các bạn có thể muốn dùng thử.

auryn

Cảm ơn vì tất cả những lời tốt đẹp mà tôi đã nhận được. Hãy chia sẻ bài viết để ngày càng nhiều người được hưởng lợi.

Nếu bạn học được dù chỉ một hoặc hai điều, hãy chia sẻ câu chuyện này!