Dependency Inversion Principle

Ngày 24 tháng 10 năm 2017 | 134 views

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 Sự Phụ Thuộc.

  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.)

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àycá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.

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).

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.

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);
    }
}

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);
}

Trong thực tế, người ta thường áp dụng pattern Dependency Injection để đảm bảo nguyên lý DIP trong code.

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

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

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.

Hiểu Về Synchronized Trong Java

Ngày 13 tháng 9 năm 2018

13-09-2018
56
Interface Segregation Principle

Ngày 24 tháng 10 năm 2017

24-10-2017
146
Single Responsibility Principle

Ngày 16 tháng 10 năm 2017

16-10-2017
170