Dependency Inversion là gì? Tất tần tật về nguyên lý thứ 5 trong SOLID
By Phạm Thanh Long- Development
- 10/09/2024
- 14 minutes read
- 351 Views
Trong thiết kế và lập trình sẽ có rất nhiều quy tắc khác nhau mà lập trình viên phải tuân thủ và áp dụng, trong đó có Dependency Inversion. Vậy Dependency Inversion là gì và nguyên lý thứ 5 trong SOLID được thể hiện như thế nào? Hãy cùng Pho Tue Software Solutions giúp bạn khám phá câu trả lời ở bài viết dưới đây!
Dependency Inversion là gì?
Dependency Inversion được hiểu là nguyên lý đảo ngược sự phụ thuộc. Đây là một trong năm nguyên lý SOLID quan trọng trong thiết kế phần mềm hướng đối tượng, được giới thiệu bởi Robert C. Martin. Nguyên lý này giúp cải thiện tính linh hoạt và khả năng bảo trì của mã nguồn bằng cách giảm sự phụ thuộc giữa các module.
Dependency Inversion là gì?
Hiểu một cách đơn giản thay vì các module cấp cao (thường là các module quản lý logic nghiệp vụ) phụ thuộc trực tiếp vào các module cấp thấp (thường là các module xử lý chi tiết kỹ thuật), cả hai nên phụ thuộc vào các interface hoặc abstract class. Bằng cách này, các module cấp cao và cấp thấp có thể phát triển độc lập và dễ dàng thay đổi mà không ảnh hưởng lớn đến hệ thống tổng thể.
Các nguyên lý trong SOLID
SOLID là một tập hợp các nguyên lý thiết kế phần mềm nhằm mục đích tạo ra các hệ thống phần mềm dễ bảo trì, mở rộng. Trong SOLID sẽ gồm có 5 nguyên lý sau đây:
Single Responsibility Principle
Một lớp chỉ nên có một lý do duy nhất để thay đổi, tức là nó chỉ nên có một trách nhiệm duy nhất. Điều này giúp giảm thiểu sự phức tạp và cải thiện khả năng bảo trì của hệ thống.
Open/Closed Principle
Các thực thể phần mềm (lớp, module, hàm,...) nên được mở để mở rộng, nhưng đóng để sửa đổi. Nó có nghĩa là bạn có thể mở rộng chức năng của một lớp mà không cần phải thay đổi mã nguồn của nó.
Liskov Substitution Principle
Các đối tượng của một lớp con phải có thể thay thế cho các đối tượng của lớp cha mà không làm thay đổi tính đúng đắn của chương trình. Từ đó đảm bảo rằng các lớp con có thể thay thế lớp cha mà không gây ra lỗi.
Interface Segregation Principle
Khách hàng không nên bị buộc phải phụ thuộc vào các giao diện mà họ không sử dụng. Nguyên lý này đề xuất rằng các giao diện nên được chia nhỏ để các lớp không cần phải triển khai các phương thức mà chúng không cần.
Dependency Inversion Principle
Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào các abstraction (abstraction). Thay vì phụ thuộc vào các lớp cụ thể, các module nên phụ thuộc vào các giao diện hoặc các lớp trừu tượng để dễ dàng thay đổi và mở rộng.
Nội dung chính trong nguyên tắc Dependency Inversion
Dependency Inversion là một trong năm nguyên tắc SOLID của lập trình hướng đối tượng. Nguyên tắc này sẽ có 2 nội dung chính sau đây:
Abstractions không nên phụ thuộc vào Details
Các lớp trừu tượng (interfaces hoặc abstract classes) không nên phụ thuộc vào các lớp cụ thể (concrete classes). Ngược lại, các lớp cụ thể nên phụ thuộc vào các lớp trừu tượng. Khi các lớp trừu tượng không phụ thuộc vào các chi tiết cụ thể, hệ thống sẽ trở nên ổn định hơn. Các thay đổi trong các lớp cụ thể sẽ không ảnh hưởng đến các lớp trừu tượng, giúp việc bảo trì và mở rộng hệ thống trở nên dễ dàng hơn.
Details nên phụ thuộc vào Abstractions
Các lớp cụ thể (implementation classes) nên phụ thuộc vào các lớp trừu tượng. Điều này có nghĩa là các chi tiết triển khai nên dựa trên các hợp đồng trừu tượng, không phải ngược lại. Nó giúp đảm bảo rằng các thay đổi trong các lớp cụ thể sẽ ít ảnh hưởng đến các lớp khác trong hệ thống. Nó cũng làm tăng tính khả chuyển của hệ thống, vì bạn có thể dễ dàng thay thế các lớp cụ thể mà không cần thay đổi các lớp trừu tượng.
Ưu, nhược điểm của Dependency Inversion
Dependency Inversion sở hữu các ưu điểm và nhược điểm sau đây:
Về ưu điểm
Giảm sự phụ thuộc giữa các module: Dependency Inversion giúp giảm sự phụ thuộc trực tiếp giữa các module cấp cao và các module cấp thấp, khiến cho hệ thống dễ dàng thay đổi và mở rộng hơn.
Tăng khả năng tái sử dụng mã nguồn: Các module trở nên độc lập hơn và có thể tái sử dụng trong các ứng dụng khác nhau mà không cần sửa đổi nhiều.
Cải thiện khả năng bảo trì: Việc thay đổi và bảo trì hệ thống dễ dàng hơn vì sự thay đổi trong một module ít ảnh hưởng đến các module khác.
Tăng tính linh hoạt: Các module cấp cao có thể tương tác với nhiều module cấp thấp khác nhau thông qua giao diện để tăng tính linh hoạt và khả năng mở rộng của hệ thống.
Hỗ trợ viết unit test dễ dàng hơn: Bằng cách tách các module thông qua giao diện, chúng ta có thể dễ dàng mock hoặc stub các module phụ thuộc, giúp việc viết và kiểm thử unit test trở nên đơn giản hơn.
Nhược điểm
Tăng độ phức tạp ban đầu: Việc thiết kế hệ thống theo nguyên tắc Dependency Inversion có thể phức tạp hơn so với việc kết nối trực tiếp các module, đặc biệt là đối với các dự án nhỏ hoặc mới bắt đầu.
Cần thêm code và tài liệu: Khi dùng giao diện hoặc các lớp trừu tượng để tách các module đòi hỏi thêm công việc viết mã và tài liệu, tăng khối lượng công việc ban đầu.
Khả năng hiệu suất bị ảnh hưởng: Các lớp trừu tượng và giao diện có thể tạo ra một lớp bổ sung giữa các module, gây ra một chút chi phí hiệu suất, mặc dù trong hầu hết các trường hợp, ảnh hưởng này là không đáng kể.
Khó khăn trong việc kiểm soát các module: Khi số lượng các module và giao diện tăng lên, việc quản lý và kiểm soát các module này có thể trở nên khó khăn hơn.
Cần sự hiểu biết sâu về thiết kế: Để áp dụng Dependency Inversion một cách hiệu quả, các nhà phát triển cần có sự hiểu biết sâu về thiết kế phần mềm và các mẫu thiết kế, điều này có thể đòi hỏi thời gian và công sức đào tạo.
Tại sao việc sử dụng Dependency Inversion lại cực kỳ quan trọng?
Dependency Inversion được đánh giá là cực kỳ quan trọng vì sở hữu các lý do sau đây:
Giảm sự phụ thuộc: Khi các module cấp cao phụ thuộc trực tiếp vào các module cấp thấp, bất kỳ thay đổi nào ở module cấp thấp cũng có thể ảnh hưởng đến module cấp cao. Từ đó làm cho hệ thống dễ bị lỗi và khó bảo trì. Bằng cách sử dụng các trừu tượng, sự phụ thuộc này được giảm thiểu, giúp hệ thống trở nên linh hoạt hơn.
Tăng tính tái sử dụng: Các module có thể dễ dàng tái sử dụng và mở rộng mà không cần thay đổi nhiều. Bởi vì các module cấp cao chỉ phụ thuộc vào các trừu tượng, chúng có thể dễ dàng sử dụng lại với các module cấp thấp khác nhau chỉ cần chúng tuân theo cùng một trừu tượng.
Dễ thay thế thành phần: Việc thay thế một thành phần này bằng một thành phần khác trở nên dễ dàng hơn khi tất cả đều tuân theo cùng một trừu tượng. Nó rất quan trọng khi cần nâng cấp hoặc sửa chữa một phần của hệ thống mà không ảnh hưởng đến toàn bộ hệ thống.
Dễ dàng kiểm thử: Bằng cách phụ thuộc vào các trừu tượng, việc kiểm thử các module riêng lẻ trở nên dễ dàng hơn. Bạn có thể dễ dàng mock hoặc stub các trừu tượng khi viết các unit test, giúp việc kiểm thử các module độc lập với các thành phần khác trong hệ thống.
Tăng khả năng linh hoạt: Dependency Inversion giúp tăng tính linh hoạt của hệ thống, cho phép bạn thay đổi cách thức hoạt động của các module mà không ảnh hưởng đến các module khác. Nó đặc biệt quan trọng trong các dự án lớn, phức tạp, nơi mà các yêu cầu có thể thay đổi thường xuyên.
Một số ví dụ về Dependency Inversion
Dependency Injection
Đây là một kỹ thuật triển khai Dependency Inversion. Thay vì một đối tượng tạo ra và sử dụng trực tiếp các đối tượng phụ thuộc của nó, nó nhận các phụ thuộc từ bên ngoài (thông qua constructor, setter method, hay interface).
Ví dụ:
public class UserService { private final UserRepository userRepository; // Constructor Injection public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public void createUser(User user) { userRepository.save(user); } } Trong ví dụ này, UserService nhận UserRepository qua constructor. Điều này cho phép UserService không phụ thuộc trực tiếp vào một implementation cụ thể của UserRepository, mà có thể sử dụng bất kỳ implementation nào tuân thủ UserRepository interface.
Interfaces và Abstract Classes
Định nghĩa các interfaces hoặc abstract classes để tạo ra các lớp phụ thuộc. Các lớp cụ thể sau đó triển khai các interfaces hoặc kế thừa từ abstract classes này.
public interface Logger { void log(String message); } public class FileLogger implements Logger { @Override public void log(String message) { // Implement log to file } } public class ConsoleLogger implements Logger { @Override public void log(String message) { // Implement log to console } } public class UserManager { private final Logger logger; // Constructor Injection public UserManager(Logger logger) { this.logger = logger; } public void addUser(String username) { // Add user logic logger.log("User added: " + username); } } Trong ví dụ này, UserManager nhận Logger qua constructor. UserManager không biết hoặc quan tâm tới cách Logger được triển khai (FileLogger hay ConsoleLogger). Điều này giúp tách biệt giữa logic kinh doanh (UserManager) và việc ghi log.
Events và Callbacks
Sử dụng các events hoặc callbacks để xử lý các sự kiện và thông báo giữa các thành phần mà không cần phụ thuộc trực tiếp vào các thành phần khác.
public interface PaymentListener { void onPaymentSuccess(); void onPaymentFailure(); } public class PaymentProcessor { private final PaymentListener listener; // Constructor Injection public PaymentProcessor(PaymentListener listener) { this.listener = listener; } public void processPayment() { // Process payment logic boolean paymentSuccess = true; // Example result if (paymentSuccess) { listener.onPaymentSuccess(); } else { listener.onPaymentFailure(); } } } PaymentProcessor sử dụng PaymentListener để thông báo kết quả thanh toán mà không cần biết cụ thể implementation của PaymentListener.
Trên đây là lời lý giải liên quan đến Dependency Inversion và thông tin liên quan đến 5 nguyên tắc trong SOLID. Hãy tiếp tục đón đọc những bài viết tiếp theo của chúng tôi để có thể cập nhật các thông tin về công nghệ mới nhất.
Phạm Thanh Long
Pho Tue SoftWare Solutions JSC là Nhà Cung cấp dịch Trung Tâm Dữ Liệu, Điện Toán Đám Mây Và Phát Triển Phần Mềm Hàng Đầu Việt Nam. Hệ Thống Data Center Đáp Ứng Mọi Nhu Cầu Với Kết Nối Internet Nhanh, Băng Thông Lớn, Uptime Lên Đến 99,99% Theo Tiêu Chuẩn TIER III-TIA 942.
Leave a comment
Your email address will not be published. Required fields are marked *