Nguyên lý SOLID là gì? Cách giải trình SOLID đơn giản và dễ hiểu nhất

Nguồn gốc của nguyên lý SOLID là gì ?

Lập trình hướng đối tượng người dùng còn được gọi là Object Oriented Programming ( OOP ). OOP là phương pháp lập trình được cho phép lập trình viên sử dụng những code để trừu tượng hóa một đối tượng người tiêu dùng bất kể. Quá trình này sẽ giúp tạo ra những đối tượng người tiêu dùng nhất định. Đây là một trong những phương pháp lập trình được sử dụng thông dụng nhất lúc bấy giờ. Nó tương thích với hầu hết những loại ngôn từ lập trình khác nhau .Hiệu năng của OOP được quyết định hành động dựa trên 4 yếu tố khác nhau :

• Tính trừu tượng (abstraction): Bằng việc sử dụng các lớp trừu tượng, người dùng sẽ tạo nên mô hình của các đối tượng trong thế giới thực.
• Tính đóng gói (Encapsulation): Yếu tố này là để chỉ trường hợp các thực thể của lớp trừu tượng sở hữu những giá trị thuộc tính độc lập.
• Tính kế thừa (Inheritance): Yếu tố này cho phép các đối tượng được phép kế thừa và mở rộng lẫn nhau.
• Tính đa hình (Polymorphism): Tùy theo từng loại đối tượng khác nhau, ta có thể thực hiện một quy trình bằng nhiều cách riêng biệt.

Vậy là ta đã nắm được 4 yếu tố cần thiết để một lập trình OOP có thể phát huy hết tác dụng vốn có của nó. Vậy SOLID thì liên quan gì đến OOP? Nguyên tắc SOLID được hiểu như một cẩm nang hướng dẫn bạn sử dụng OOP thật hiệu quả. Tuân thủ theo các nguyên tắc SOLID giúp người dùng phối hợp được 4 tính năng của OOP với nhau thật nhuần nguyễn.

Khái niệm của nguyên lý SOLID

Nguyên lý SOLID nghĩa là gì ? SOLID trong lập trình vốn là bộ 5 nguyên tắc được tăng trưởng bởi 2 tác giả Bob Martin và Michael Feathers. Những hướng dẫn này sẽ giúp lập trình viên tạo ra được những đoạn code dễ đọc, dễ hiểu, dễ maintain. SOLID là viết tắt của 5 cụm từ sau :

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

Nguyên tắc nghĩa vụ và trách nhiệm đơn lẻ ( Single Responsibility Principle )

Nguyên lý SOLID này cho rằng, mỗi class chỉ nên thực thi một nghĩa vụ và trách nhiệm duy nhất. Người dùng không nên cho một class kiêm nhiệm nhiều hoạt động giải trí cùng lúc. Thứ nhất, việc phải chia thời hạn và sức lực lao động cho nhiều việc làm sẽ làm giảm hiệu suất hoạt động giải trí. Hơn nữa nó còn mất thời hạn khi phải chuyển dời từ việc làm này sang việc làm khác. Ngoài ra, việc chạy đồng thời nhiều tiến trình một lúc cũng rất dễ xảy ra lỗi .Ví dụ, bạn có một lớp A. Bạn cho lớp A chạy cả việc làm X và việc làm Y. Có thể thời hạn đầu bạn sẽ thấy cách làm này tiết kiệm ngân sách và chi phí thời hạn tạo những lớp và gán đối tượng người tiêu dùng hơn. Tuy nhiên, khi số lượng việc làm tăng lên, liệu rằng bạn có liên tục cho lớp A chạy thêm việc làm Z, W, J … Open phía sau hay không ? Mỗi lần có thêm một việc làm, lập trình viên sẽ phải vào lại lớp A và chỉnh sửa hàng loạt mạng lưới hệ thống. Như vậy rất mất thời hạn và còn dễ xảy ra sai sót trong quy trình thay thế sửa chữa. Chưa kể đến việc khi một trong những việc làm cần tạm dừng, người dùng cũng phải lật lại hàng loạt mạng lưới hệ thống của A để làm lại .Vậy nên, những tốt nhất để hạn chế hàng loạt những rủi ro đáng tiếc như vậy là cho mỗi lớp một tính năng riêng không liên quan gì đến nhau. Không nên gộp nhiều hoạt động giải trí vào cùng một lớp .

Nguyên tắc đóng mở ( The Open-Closed Principle )

Nguyên tắc đóng mở được dùng để mô tả hoạt động kế thừa của các lớp. Ví dụ, với một nhân viên công tác tại công ty, anh ta đang làm việc rất tốt, vì thế ngoài lương cứng anh ta sẽ có thêm một khoản tiền thưởng. Với trường hợp như vậy, lựa chọn của bạn là lập thêm một lớp mới cho khoản thưởng (dựa trên nguyên tắc đơn lẻ phía trên) đúng hay không? Điều này khả thi nhưng không hiệu quả. Nếu như anh ta có thêm một khoản thưởng nữa thì sao, khi ấy chúng ta lại phải quay lại và sửa lớp đại diện cho tiền thưởng ư? Chắc chắn là không nên làm như vậy. Lập trình hạn chế nhất là chỉnh sửa bởi nó đem lại rủi ro về sai phạm là rất cao.

Vậy nên trong trường hợp này, bạn nên sử dụng một lớp thừa kế. Nguyên lý SOLID này được cho phép đóng lớp tiền lương và mở lớp tiền thường. Tức là lớp chính tiền lương cố định và thắt chặt sẽ không bị chịu bất kể ảnh hưởng tác động nào cả. Còn lớp thưởng sẽ nhận được sự thừa kế của lớp lương để bổ trợ những thông tin thiết yếu. Quy trình này lê dài đến vô hạn những lớp sau. Đây là giải pháp rất bảo đảm an toàn và thiện thiện, vừa giúp tăng trưởng code mới mà lại không lo làm hỏng code cũ .

Nguyên tắc phân vùng Liskov ( The Liskov Substitution Principle )

Phân vùng Liskov là một trong những phần quan trọng của nguyên lý SOLID. Nguyên tắc này giúp xử lý những lỗi thường xảy ra trong lập trình .Ví dụ : Có một đoạn mã diễn đạt những loài chim biết bay. Khi gặp một loài chim không biết bay như chim cánh cụt, nó sẽ được gắn với NoFlyException. Tuy nhiên, nếu chim cánh cụt lại liên tục Open ở vòng lặp main, chương trình sẽ tự động hóa quăng Exception. Đó chính là thực chất của nguyên tắc phân vùng .Để xử lý điều này, ta cần phải tách lớp chim cánh cụt ra một interface riêng. Nguyên tắc này Open là để nhắc nhở lập trình viên quan tâm đến tính sai phạm của nội dung những đoạn mã lập trình. Nếu không khi để đến lúc triển khai xong mới phát hiện ra lỗi thì sửa lại rất khó khăn vất vả và mất thời hạn .

Nguyên tắc phân tách giao diện ( Interface Segregation Principle )

Trường hợp thực tế của nguyên tắc này như sau: Bạn sở hữu một trung tâm cung cấp các gói du lịch bao gồm những sản phẩm như: gói 1, gói 2, gói 3… Các khách hàng cùng sử dụng một gói sẽ được cho vào một interface chung. Thời gian ban đầu, bạn thấy cách quản lý này rất hợp lý rồi. Tuy nhiên, bỗng có những khách hàng muốn sử dụng một gói bao gồm một vài dịch vụ trong gói 1 cùng một số dịch vụ khác trong gói 2. Thế là bỗng dưng có những gói mới được phát sinh. Càng ngày có càng nhiều khách hàng yêu cầu gói riêng như vậy. Nếu ta cứ viết chung vào trong interface gói du lịch như vậy thì sẽ phải implement nhiều hàm không cần thiết.

Ta sẽ xử lý trường hợp này bằng nguyên tắc phân tách giao diện. Hãy tách những dịch vụ thành những interface đơn cử khác nhau. Khi đó, người mua nhu yếu dịch vụ nào, ta gộp dịch vụ đó thành một gói mới cho khách. Nguyên lý SOLID này giúp bạn thuận tiện lan rộng ra quy mô một cách đơn thuần .

Nguyên tắc đảo ngược phụ thuộc vào ( Dependency Inversion Principle )

Nội dung của nguyên lý SOLID này nói về việc những thành phần đơn cử nên nhờ vào vào những thành phần trừu tượng. Lý do là vì những thành phần trừu tượng thường ít bị biến hóa. trái lại, những thành phần đơn cử tuy khác nhau nhưng luôn mang một đặc tính chung để cấu thành thành phần trừu tượng. Việc giữ tính nhờ vào này giúp chương trình thích ứng tốt với những đổi khác liên tục .

Kết luận về nguyên lý SOLID

Với bài lý giải vừa qua của Teky, hẳn bạn đọc đã hiểu rõ 5 nguyên lý SOLID dành cho OOP. Tuy nhiên hiểu là một chuyện mà vận dụng thuần thục được lại là chuyện khác. Lời khuyên của chúng tôi là hãy ghi nhớ thật rõ ràng và tiếp tục vận dụng những nguyên tắc này vào trong việc làm của bạn. Chúc bạn sớm ngày chinh phục được những nguyên lý SOLID !

Source: https://laodongdongnai.vn
Category: Chia Sẻ Kiến Thức