Series SOLID cho thanh niên code CỨNG: Dependency Inversion Principle

Giới thiệu

Chào mừng các bạn đến với bài viết cuối cùng trong series SOLID. Ở bài viết này, mình sẽ nói về Dependency Inversion Principle – Nguyên lý Đảo Ngược Dependency.

  1. Single Responsibility Principle
  2. Open/Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion Principle

Nội dung nguyên lý

1. Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
2. Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại. (Các class giao tiếp với nhau thông qua interface, không phải thông qua implementation.)

dependency_inversion_principle_thumb

Giải thích nguyên lý

Trong bài, mình hay dùng từ module. Trong thực tế, module này có thể là 1 project, 1 file dll, hoặc một service. Để dễ hiểu, chỉ trong bài viết này, các bạn hãy xem mỗi module là một class nhé.

Với cách code thông thường, các module cấp cao sẽ gọi các module cấp thấp. Module cấp cao sẽ phụ thuộc và module cấp thấp, điều đó tạo ra các dependency. Khi module cấp thấp thay đổi, module cấp cao phải thay đổi theo. Một thay đổi sẽ kéo theo hàng loạt thay đổi, giảm khả năng bảo trì của code.

ioc-and-mapper-in-c-4-638

Nếu tuân theo DIP, các module cấp thấp lẫn cấp cao đều phụ thuộc vào 1 interface không đổi. Ta có thể dễ dàng thay thế, sửa đổi module cấp thấp mà không ảnh hưởng gì tới module cấp cao.

Để dễ hiểu, bạn hãy nhìn vào cái mấy cái đèn điện trong nhà mình. Ở đây, module cấp cao chính là ổ điện, interface chính là đuôi đèn tròn, 2 module cấp thấp là bóng đèn tròn bóng đèn huỳnh quang.

Hai module này đều kế thừa interface đuổi tròn, Ta có thể dễ dàng thay đổi 2 loại bóng vì module cấp cao (ổ điện) chỉ quan tâm tới interface (đuôi tròn), không quan tâm tới implementation (bóng đèn tròn hay huỳnh quang).

abcd

Trong code cũng vậy, khi áp dụng DIP, các module liên kết với nhau thông qua interface. Để kết nối tới database, ta chỉ cần gọi hàm Get, Save … của interface IDataAccess. Khi thay database, ta chỉ cần thay implementation của interface này.

dependency-inversion_principles
Abstraction ở đây chính là interface

Ví dụ minh họa

Code khi chưa áp dụng DIP:

Code sau khi đã thiết kế lại, áp dụng DIP:

Trong thực tế, người ta thường áp dụng pattern Dependency Injection để đảm bảo nguyên lý DIP trong code. Mình đã giải thích kĩ về code trong bài viết này nên không nhắc lại nữa, các bạn vào xem nhé: https://toidicodedao.com/2015/11/10/dependency-injection-va-inversion-of-control-phan-2-ap-dung-di-vao-code/

ioc-and-mapper-in-c-8-638

Lưu ý và kết luận

DIP được áp dụng nhiều nhất trong code, nhưng nó cũng gây ra nhiều điều tranh cãi. Bên cạnh một số ưu điểm, DIP cũng đi kèm một số khuyết điểm sau:

ƯU ĐIỂM KHUYẾT ĐIỂM
  • Giảm sự kết dính giữa các module
  • Code dễ bảo trì, dễ thay thế module
  • Rất dễ test và viết Unit Test
  • Khái niệm DI khá “khó tiêu”, các developer mới sẽ gặp khó khăn khi học
  • Sử dụng interface nên đôi khi sẽ khó debug, do không biết chính xác module nào được gọi
  • Làm tăng độ phức tạp của code

Mình từng gặp một số dự án mà mỗi interface chỉ có 1 class implement nó, cũng không có Unit Test gì cả. Trong trường hợp này, DIP không mang lại nhiều lợi ích, áp dụng DI chỉ khiến cho code dài dòng, khó debug hơn.

ioc-and-mapper-in-c-1-638

Một số tài liệu để tham khảo thêm:

Lời kết

Chúc mừng các bạn đã cùng mình hoàn thành series SOLID cho thanh niên code cứng này. Hi vọng qua series, các bạn có thể thu được những kiến thức hữu ích và áp dụng chúng vào việc thiết kế/ viết code.

Như mình đã nói ở bài đầu tiên,  các nguyên lý này chỉ là hướng dẫn, giúp cho code của bạn tốt hơn, sạch hơn, dễ bảo trì hơn. Tuy nhiên, “không có bữa ăn trưa nào miễn phí”. Áp dụng các nguyên lý này vào code có thể giúp bạn cải thiện được chất lượng code, nhưng cũng có thể làm nó rườm rà, dài hơn, khó quản lý hơn.

Nhắc lại một điều mình đã nói trong bài design pattern: Để thành một developer giỏi, ta nên biết các nguyên lý SOLID, các design patterns. Tuy nhiên, không phải cứ cứng nhắc áp dụng nhiều nguyên lý và design pattern vào code thì code sẽ tốt hơn. Một người developer giỏi sẽ hiểu rõ những trade-off của chúng và chỉ áp dụng một cách hợp lý để giải quyết vấn đề. Hãy nhớ, trong design, tất cả đều là đánh đổi nhé!

1
Đừng để code của bạn biến thành thế này nhé
Advertisements

8 thoughts on “Series SOLID cho thanh niên code CỨNG: Dependency Inversion Principle”

  1. “Mình từng gặp một số dự án mà mỗi interface chỉ có 1 class implement nó, cũng không có Unit Test gì cả.”
    —> Móa nhột quá nha honey! Đúng là có 1 class nhưng hên là có Unit Test gỡ gạc lại.

    Liked by 1 person

  2. Lúc trước đi phỏng vấn gặp 1 ông nói:
    – IDatabase db = new Database();
    – db.Save(orderId);
    là vi phạm nguyên tắc DI Injection. Hắn cho rằng dùng từ khóa new là vi phạm nguyên tắc -> làm mình hoang mang quá. Bác chủ thớt cho cái ví dụ sâu hơn để tìm hiểu thêm đi.

    Like

    1. đúng rồi đó bạn mình cũng mới học spring thấy các đối tượng hay các beans đều được tạo ra và quản lý bởi container hết , mình chỉ khai báo bằng file xml và anotation thôi ,

      Like

  3. Theo mình, để thể hiện về DIP triệt để hơn, hàm checkout chỉ cần biết đến database là 1 service chuyên thực thi các hàm lưu trữ, cập nhật dữ liệu, ko cần quan tâm đến việc khởi tạo nó như thế nào.
    Do vậy trong ví dụ code về DIP của bạn mình thấy có chỗ chưa ổn lắm:

    IDatabase db = new Database();
    db.Save(orderId);

    Một instance của db vẫn được khởi tạo bằng từ khóa new, như vậy nếu chúng ta thay đổi constructor của IDatabase, cho thêm tham số connectionString chẳng hạn, thì sự thay đổi từ module cấp thấp (Database) sẽ làm chúng ta phải sửa code ở module cấp cao (thêm biến connectionString vào hàm khởi tạo của database ở hàm checkout). Như vậy vẫn vi phạm DIP.

    Like

    1. Ở đây có thể dùng 1 service khác để inject object database vào, mình khai báo new để các bạn đọc dễ hiểu về DIP thôi. Trong bài viết mình có để link tới cách làm đúng là Dependency Injection nhé bạn. Thanks bạn đã góp ý ;).

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s