- Nguyên lí SOLID là gì ? Để trở thành 1 developer giỏi thì phải thành thục nguyên lí này
- Single Responsibility Principle – Nguyên lí đơn trách nhiệm
- Open/Closed Principle – Nguyên lí đóng mở thế giới
- Liskov Substitution principle – Nguyên lí thay thế Liskow
- Interface Segregation Principle – Nguyên lí phân biệt interface
- Dependency inversion principle – Nguyên lí nghịch đảo phụ thuộc
Mình xin nhắc lại một chút về nguyên lí này. Single Responsibility Principle tương ứng với chữ S trong SOLID: Mỗi module hoặc class chỉ phải chịu một trách nhiệm duy nhất, tất cả các dịch vụ của nó phải được liên kết chặt chẽ với trách nhiệm đó. Robert Cecil Martin đã phát biểu nguyên lí này theo cách khác, do một class chỉ chịu một trác nhiệm duy nhất nên “chỉ có một lí do duy nhất để hay đổi”.
Bạn có thể thấy hình trên thay vì sử dụng nhiều công công cụ như đục, thước, búa, cưa, kìm thì tất cả chủ được gộp thành một công cụ duy nhất, mình tạm gọi tên nó là thứ-nhảm-nhất-mà-ai-cũng-thấy-được. Nếu là bạn bạn sẽ chọn cái nào, giả sử một ngày project của bạn thay đổi, và bạn cần thêm 1 chức năng khác vào project của mình, thì thứ-nhảm-nhất-mà-ai-cũng-thấy-được chắc chắn sẽ không thể thay đổi hay sửa được, dù sửa bạn cũng sẽ phải tháo bung mọi thứ ra, còn để sửa cái búa, cưa, thước… thì chuyện này sẽ đơn giản hơn nhiều. Với cái thước thì chỉ có lí do duy nhất thay đổi nó là đổi cách đo, còn thứ-nhảm-nhất-mà-ai-cũng-thấy-được thì có N lí do khác nhau.
Chắc hẳn bạn nào cũng đã được làm quen với một bài tập huyền thoại đó là chương trình quản lí sinh viên. Đó chỉ là bài tập khá là cơ bản để bạn làm quen dần với code nhưng cũng đã vi phạm nguyên lí Single Responsibility Principle một cách sâu sắc.
public class SinhVien { // chưa thông tin sinh viên
protected String maSV;
protected String tenSV;
// constructer, get and set ở đây
public double tinhDiemTB (String maSV) {
}
public double tinhDiemTBMon (String maSV, String maMon) {
}
public String xepLoai (String maSV, String maHK) {
}
/// còn nhiều thứ ỏ đây nữa
}
Bạn nhìn qua thì có vẻ khá là bình thường nhưng bạn nghĩ đến một tương lai gần những chức năng không còn đơn giản như thế này nữa, bạn cần thêm chức năng tính điểm sinh viên, tính học phí… thì cái class SinhVien huyền thoại ngày nào sẽ to dần ra, cộng thêm khả năng viết code “khó mà đọc được” nữa thì bạn có thể không tiếp tục phát triển nó thành một chương trình hoàn hảo được được nữa.
Để khoa học hơn, hãy thử áp dụng Single Responsibility Principle giúp bạn. Chia class SinhVien ra thành các class nhỏ hơn, mỗi class có một công việc duy nhất, cụ thể:
public class SinhVien {
protected String maSV;
protected String tenSV;
// constructer, get and set ở đây
}
// hàm này chỉ tính điểm
public class TinhDiem {
public double tinhDiemTB (SinhVien sv) {
}
public double tinhDiemTBMon (SinhVien sv, String maMon) {
}
}
// hàm này chỉ xếp loại sinh viên
public class XepLoai {
public String xepLoai (SinhVien sv) {
}
public String xepLoaiHocKy (SinhVien sv, String maHK) {
}
}
Khi chia nhỏ class Sinhvien thì khi một người khác nhìn vào project của bạn cũng cảm thấy được sự khoa học, sau này dù nâng cấp nhiều thì bạn cũng sẽ dễ dàng hơn, code ngắn cũng sẽ ít bug. Hy vọng qua ví dụ nho nhỏ này bạn có thể hiểu thêm về nguyên lí này bạn có thể làm project của mình sáng sủa hơn, dễ đọc hơn. Nhưng bạn cũng phải lưu ý, không nhất thiết mọi thứ đều phải tuân thủ theo, hãy cân nhắc tùy vào từng trường hợp mà có cách làm cụ thể.
