Home › Không tìm thấy trang

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 và 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:


// Cart là module cấp cao
public class Cart
{
public void Checkout(int orderId, int userId)
{
// Database, Logger, EmailSender là module cấp thấy
Database db = new Database();
db.Save(orderId);
Logger log = new Logger();
log.LogInfo("Order has been checkout");
EmailSender es = new EmailSender();
es.SendEmail(userId);
}
}

view raw

Cart.cs

hosted with ❤ by GitHub

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


// Interface
public interface IDatabase
{
void Save(int orderId);
}
public interface ILogger
{
void LogInfo(string info);
}
public interface IEmailSender
{
void SendEmail(int userId);
}
// Các Module implement các Interface
public class Logger : ILogger
{
public void LogInfo(string info) {}
}
public class Database : IDatabase
{
public void Save(int orderId) {}
}
public class EmailSender : IEmailSender
{
public void SendEmail(int userId) {}
}
// Hàm checkout mới sẽ như sau
public void Checkout(int orderId, int userId)
{
// Nếu muốn thay đổi database, logger ta chỉ cần thay dòng code dưới
// Các Module XMLDatabase, SQLDatabase phải implement IDatabase
//IDatabase db = new XMLDatabase();
//IDatebase db = new SQLDatabase();
IDatabase db = new Database();
db.Save(orderId);
ILogger log = new Logger();
log.LogInfo("Order has been checkout");
IEmailSender es = new EmailSender();
es.SendEmail(userId);
}

view raw

interface.cs

hosted with ❤ by GitHub

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ỂMKHUYẾ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é

Discover more from Từ coder đến developer - Tôi đi code dạo

Subscribe to get the latest posts sent to your email.

Hãy là người đẹp trai từ những câu nói.

Subscribe to: Post Comments (Atom)