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. 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ả ...
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.
Nội dung nguyên lý
|
1 2 3 4 |
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à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.
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.
Abstraction ở đây chính là interface
Ví dụ minh họa
Code khi chưa áp dụng DIP:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
// 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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
// 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. 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/
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 |
|---|---|
|
|
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.
Một số tài liệu để tham khảo thêm:
- http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- https://lostechies.com/derickbailey/2011/09/22/dependency-injection-is-not-the-same-as-the-dependency-inversion-principle/
- http://www.codeproject.com/Articles/538536/A-curry-of-Dependency-Inversion-Principle-DIP-Inve
- http://www.codeproject.com/Articles/615139/An-Absolute-Beginners-Tutorial-on-Dependency-Inver
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é!
Đừng để code của bạn biến thành thế này nhéTechtalk via Toidicodedao
