1. Cơ bản về SOLID
SOLID là 5 nguyên tắc giúp mình viết code dễ hiểu, dễ sửa, dễ mở rộng và ít gây lỗi khi thay đổi. SOLID thường được sử dụng trong lập trình hướng đối tượng. Có thể hiểu đơn giản là thay vì viết một đoạn code làm quá nhiều việc hoặc các phần phụ thuộc chặt chẽ vào nhau, mình chia code thành những phần có trách nhiệm rõ ràng và dễ thay đổi hơn.
Nói chung là mục đích cuối cùng của SOLID là giúp code sạch hơn, dễ hiểu hơn, dễ bảo trì hơn và dễ mở rộng hơn khi dự án phát triển.
2. S – Single Responsibility Principle
S có nghĩa là một Class nên tập trung làm một việc chính. Nếu một Class vừa xử lý đơn hàng, vừa lưu Database, vừa gửi Email thì khi sửa một chức năng có thể ảnh hưởng đến những chức năng khác. Vì vậy nên chia mỗi nhiệm vụ thành một phần riêng. Hiểu đơn giản: một Class làm tốt một việc còn hơn một Class làm quá nhiều việc.
3. O – Open và Closed Principle
O có nghĩa là có thể mở rộng chức năng nhưng hạn chế sửa code cũ. Khi cần thêm một tính năng mới, mình nên tạo thêm phần mới để mở rộng hệ thống thay vì sửa quá nhiều code đang chạy ổn định. Ví dụ, hệ thống đang có thanh toán bằng thẻ, sau này muốn thêm thanh toán bằng ví điện tử thì nên thêm phương thức mới thay vì sửa toàn bộ phần thanh toán cũ. Hiểu đơn giản: thêm cái mới mà hạn chế đụng vào cái cũ.
4. L – Liskov Substitution Principle
L có nghĩa là Class con phải có thể thay thế Class cha mà chương trình vẫn hoạt động đúng. Khi sử dụng kế thừa, Class con phải tuân thủ những hành vi mà Class cha đã định nghĩa. Nếu Class con kế thừa nhưng lại không thể thực hiện đúng những gì Class cha yêu cầu thì thiết kế đó có vấn đề. Hiểu đơn giản: Class con phải dùng được như Class cha mà không làm chương trình bị lỗi.
5. I – Interface Segregation Principle
I có nghĩa là không nên bắt một Class phải sử dụng những chức năng mà nó không cần. Thay vì tạo một Interface quá lớn chứa rất nhiều chức năng, mình nên chia thành những Interface nhỏ hơn để mỗi Class chỉ sử dụng đúng những gì cần thiết. Hiểu đơn giản: không ép một Class phải làm những thứ không liên quan đến nó.
6. D – Dependency Inversion Principle
D có nghĩa là các thành phần trong hệ thống không nên phụ thuộc quá chặt vào nhau. Thay vì một phần code phụ thuộc trực tiếp vào một Database hoặc một công nghệ cụ thể, nên thông qua một Abstraction như Interface. Nhờ vậy, khi muốn đổi Database hoặc thay đổi một thành phần, mình không phải sửa quá nhiều code khác. Hiểu đơn giản: giảm sự phụ thuộc trực tiếp để dễ thay đổi và bảo trì.
7. Tổng kết dễ nhớ
Có thể nhớ SOLID theo cách dễ hiểu :
S: Một Class là Một trách nhiệm chính
O: Thêm chức năng mới là Hạn chế sửa code cũ.
L: Class con là Có thể thay thế Class cha.
I: Interface là Chia nhỏ, chỉ dùng thứ cần thiết.
D: Dependency là Giảm phụ thuộc trực tiếp.
Bài viết khác
Test Automation(Kiểm thử tự động)
1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]
Logging – Monitoring – CI/CD
Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]
Redis & Caching là gì?
Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]
Background Jobs & Queues
1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]
Saga Pattern
Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]
Two-Phase Locking (2PL)
Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]
Khoá học lập trình game con rắn cho trẻ em 
