Trong thiết kế phần mềm nói chung, Một class có quá nhiều chức năng cũng sẽ trở nên cồng kềnh và phức tạp.
Trong ngành IT, requirement rất hay thay đổi, dẫn tới sự thay đổi code.Nếu một class có quá nhiều chức năng, quá cồng kềnh, việc thay đổi code sẽ rất khó khăn, mất nhiều thời gian, còn dễ gây ảnh hưởng tới các module đang hoạt động khác.
Nguyên lý này yêu cầu mỗi class được viết ra chỉ đảm nhiệm một chức năng duy nhất và cũng chỉ có thể thay đổi class này với một lý do duy nhất.
Để có thể hiểu nguyên lý này ta đi vào ví dụ minh họa sau
Đoạn code dưới đây là ví dụ cho việc vi phạm SRP. Lỗi này hồi mới học code mình cũng hay mắc phải. Class Student có quá nhiều chức năng: chứa thông tin học sinh, format hiển thị thông tin, lưu trữ thông tin.
Code như thế thì có làm sao không? Hiện tại thì không sao cả, nhưng khi code lớn dần, thêm chức năng nhiều hơn, class Student sẽ bị phình to ra. Chưa kể, nếu như có thêm các class khác như Person, Teacher v…v, đoạn code hiển thị/lưu trữ thông tin sẽ nằm rải rác ở nhiều class, rất khó sửa chữa và nâng cấp.
Để giải quyết, ta chỉ cần tách ra làm nhiều class, mỗi class có một chức năng riêng là xong. Khi cần nâng cấp, sửa chữa, sẽ diễn ra ở từng class, không ảnh hưởng tới các class còn lại.
Chú ý:
Không phải lúc nào cũng nên áp dụng nguyên lý này vào code. Một trường hợp hay gặp là các class dạng Helper hay Utilities – các class này vi phạm SRP một cách trắng trợn. Nếu số lượng hàm ít, ta vẫn có thể cho tất cả các hàm này vào một class, xét cho cùng, toàn bộ các hàm trong helper đều có chức năng xử lý các tác vụ nho nhỏ. Tuy nhiên, khi Helper có thêm nhiều chức năng, nó trở nên phức tạp và cồng kềnh hơn. Lúc này, ta cần áp dụng SRP để chia nó thành các module nho nhỏ để dễ quản lý.
Kết luận
SRP là nguyên lý đơn giản dễ hiểu nhất, nhưng cũng khó áp dụng đúng nhất. Sự khác nhau giữa dev giỏi và dev bình thường là ở chỗ, cả 2 cùng biết về các qui tắc và nguyên lý, nhưng dev giỏi sẽ biết khi nào cần áp dụng, khi nào không.
Tiếp tục cập nhật ...
Code như thế thì có làm sao không? Hiện tại thì không sao cả, nhưng khi code lớn dần, thêm chức năng nhiều hơn, class Student sẽ bị phình to ra. Chưa kể, nếu như có thêm các class khác như Person, Teacher v…v, đoạn code hiển thị/lưu trữ thông tin sẽ nằm rải rác ở nhiều class, rất khó sửa chữa và nâng cấp.
Để giải quyết, ta chỉ cần tách ra làm nhiều class, mỗi class có một chức năng riêng là xong. Khi cần nâng cấp, sửa chữa, sẽ diễn ra ở từng class, không ảnh hưởng tới các class còn lại.
Chú ý:
Không phải lúc nào cũng nên áp dụng nguyên lý này vào code. Một trường hợp hay gặp là các class dạng Helper hay Utilities – các class này vi phạm SRP một cách trắng trợn. Nếu số lượng hàm ít, ta vẫn có thể cho tất cả các hàm này vào một class, xét cho cùng, toàn bộ các hàm trong helper đều có chức năng xử lý các tác vụ nho nhỏ. Tuy nhiên, khi Helper có thêm nhiều chức năng, nó trở nên phức tạp và cồng kềnh hơn. Lúc này, ta cần áp dụng SRP để chia nó thành các module nho nhỏ để dễ quản lý.
Kết luận
SRP là nguyên lý đơn giản dễ hiểu nhất, nhưng cũng khó áp dụng đúng nhất. Sự khác nhau giữa dev giỏi và dev bình thường là ở chỗ, cả 2 cùng biết về các qui tắc và nguyên lý, nhưng dev giỏi sẽ biết khi nào cần áp dụng, khi nào không.
Tiếp tục cập nhật ...
