SOLID, DRY, KISS, YAGNI: Các nguyên lý trong thiết kế phần mềm

08:49 10-06-2021Hoa

Các nguyên lý thiết kế phần mềm là hướng dẫn giúp cho nhà phát triển phần mềm (developers) tạo ra được một thiết kế hệ thống tốt.

SOLID

Nội dung chính của nguyên lý này được kết hợp từ 5 nguyên lý cơ bản sau:

1. Single Responsibility Principle:
Đây là nguyên lý đầu tiên (chính là chữ S đầu trong SOLID). Nguyên lý này nói rằng chỉ nên có 1 lý do để một lớp (class) thay đổi. Nghĩa là, bạn nên thiết kế sao cho mỗi class chỉ phục vụ một mục đích.

Ví dụ một kịch bản như sau: chúng ta cần một tính năng lên lịch hẹn phỏng vấn ứng viên (schedule interview). Công việc chúng ta cần làm là: lưu thông tin buổi phỏng vấn, sau đó gửi mail cho ứng viên về buổi phỏng vấn. Thay vì thiết kế một class ScheduleInterview để làm tất cả các việc trên, bạn tạo một class Interview chỉ để thực hiện công việc lưu thông tin buổi phỏng vấn, và chúng ta có thêm class EmailSending dùng để thực hiện công việc gửi mail cho ứng viên.

2. Open/Closed Priciple:

Đây là nguyên lý thứ hai (chính là chữ O trong SOLID). Nguyên lý này nói rằng các thực thể phần mềm như: class, modules, functions,… thì có thể thoải mái viết code để mở rộng nhưng nên hạn chế sửa đổi.

Từ “Closed” ở đây nghĩa là, một module đã được phát triển và tested thì code của nó chỉ được thay đổi để sửa lỗi.

Từ “Open” nghĩa là module có thể được thoải mái mở rộng từ code hiện tại để phục vụ cho tính năng mới.

Ví dụ: một lớp cơ sở PaymentGatewayBase chứa tất cả các thuộc tính và phương thức thanh toán cơ bản. Lớp này có thể được mở rộng bởi các lớp PaymentGateway khác nhau cho các cổng thanh toán khác nhau để phục vụ các chức năng của họ. Do đó, nó được mở rộng thoải mái nhưng hạn chế việc thay đổi.

3. Liscov Substitution Priciple:

Nguyên lý này nói rằng các đối tượng của lớp con có thể thay thế các đối tượng của lớp cha mà vẫn đảm bảo tính đúng đắn của chương trình.
Nói một cách dễ hiểu: chỉ cho class A kế thừa class B khi class A thay thế được class B.
Nguyên lý này đảm bảo rằng kế thừa được sử dụng đúng cách.

4. Interface Segregation Priciple:

Nguyên lý này nói rằng thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ với nhiều mục đích cụ thể.

5. Dependency Inversion Priciple (DIP):

Nguyên lý này nói rằng, 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 abstractions (interface).

Abstractions (interface) không nên phục thuộc vào chi tiết, mà ngược lại. Nghĩa là, các class nên giao tiếp với nhau thông qua interface, không phải thông qua implementation.

Ví dụ: Dependency Injection pattern là một implementation của nguyên lý này.

DRY – Don’t Repeat Yourself

Nguyên lý này nói rằng mỗi mẩu code chỉ được xuất hiện đúng một lần trong toàn bộ hệ thống. Điều này giúp chúng ta viết code mở rộng, bảo trì và có thể sử dụng lại được.

KISS – Keep it simple, Stupid!

Nguyên lý này khuyên rằng cố gắng tư duy và viết code đơn giản, tránh phức tạp hóa không cần thiết. Điều này giúp code của chúng ta dễ bảo trì.

YAGNI – You ain’t gonna need it

Nguyên lý này nói rằng chỉ code khi bạn thực sự cần, đừng bao giờ lo xa.

Chúc BKAPers sớm trở thành cao thủ phần mềm nhé!


Bachkhoa-Aptech - Tự hào 19 năm kiến tạo IT chất lượng cao

10 suất học bổng Kiến tạo IT Leader 2,5 năm tài trợ 100% học phí: THI TUYỂN LỚP CHẤT LƯỢNG CAO - IT LEADER 4.0 (bachkhoa-aptech.edu.vn)

#BachkhoaAptech #Làmtrướchọcsau #ITleader

   0968 27 6996