SOLID – Nguyên lý 1: Đơn nhiệm – Single Responsibility principle (SRP)

Bài đăng này đã không được cập nhật trong 2 năm

SOLID là gì?

SOLID là viết tắt của 5 chữ cái đầu trong 5 nguyên tắc thiết kế hướng đối tượng. Giúp cho lập trình viên viết ra những đoạn code dễ đọc, dễ hiểu, dễ maintain. Nó được đưa ra bởi Robert C. Martin và Michael Feathers. 5 nguyên lý đó bao gồm:

Single responsibility principle (SRP)
Open/Closed principle (OCP)
Liskov substitution principe (LSP)
Interface segregation principle (ISP)
Dependency inversion principle (DIP)

Trong bài viết lần này chúng ta sẽ cùng tìm hiểu về nguyên lý đầu tiên của SOLID - Single Responsibility Principle (SRP) - Nguyên lý đơn nhiệm.

Single Responsibility principle (SRP) - Đơn nhiệm

Nguyên lý này ứng với chữ S trong SOLID, có ý nghĩa là một class chỉ nên giữ một trách nhiệm (chức năng) duy nhất. Đề xác định một class giữ một hay nhiều trách nhiệm bằng cách xem xét nếu có thể nghĩ ra nhiều hơn một động cơ làm thay đổi class, thì class đó có nhiều hơn một trách nhiệm.

Tại sao phải đơn nhiệm?

Nhìn vào hình ảnh ta thấy ở trên là các dụng cụ: kìm, búa, cưa,... và ở dưới là dụng cụ đa năng - kết hợp của các dụng cụ ở bên trên. Nhìn có vẻ dụng cụ đa năng cái gì cũng có và rất tiện nhưng hãy cùng xem xét các nhược điểm khi sử dụng nó:

Dụng cụ đa năng bên dưới tuy là sự kết hợp của các dụng cụ bên trên nhưng về hiệu năng lại không bằng cái nào cả: cưa, búa quá bé, thước quá ngắn, thậm chí tuy có hình giống tay nắm của cái kìm nhưng lại không có đầu kìm để thực hiển chức năng vặn.
Khi muốn thực hiện một chức năng cụ thể như gõ đinh, thay vì chỉ dùng chiếc búa, ta sẽ phải dùng dụng cụ đa năng với 1 đống dụng cụ kết hợp, khá cồng kềnh.
Đối với trường hợp một phần nào đó trong dụng cụ đa năng bị hỏng hoặc yêu cầu được thay đổi: thay đổi độ đo của thước, tua vit đầu bé hơn..., ta sẽ phải tháo toàn bộ ra, chỉ sửa phần bị hỏng hoặc thay đổi rồi lại lắp vào, việc maintain và mở rộng trở nên khá phức tạp.

=> Kết luận: Dụng cụ đa năng quá cồng kềnh, phức tạp, khó maintain, mở rộng.

Trong lập trình cũng vậy, 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. Với sự phát triển của ứng dụng, các requirement liên tục thay đổi dẫn tới sự thay đổi code. Nếu một class quá nhiều chức năng sẽ khó thay đổi, tốn nhiều thời gian sửa chữa hơn và có thể ảnh hưởng tới các module đang chạy khác. Vì vậy, để cho việc bảo trì và mở rộng dễ dàng sau này, bạn nên thiết kế theo hướng đơn nhiệm: mỗi class chỉ nên chịu trách nhiệm về một tính năng duy nhất. Nếu xuất hiện đoạn code mà không thuộc về trách nhiệm của class, thì nên tách đoạn code đó ra một class xử lí khác.

Áp dụng

Hãy xem một ví dụ chương trình quản lý sinh viên:

Nhìn qua có vẻ khá là bình thường nhưng trong tương lai gần, khi hệ thống được mở rộng, các chức năng sẽ không đơn giản như thế này nữa, ta sẽ cần thêm chức năng tính điểm, tính học phí... thì class SinhVien sẽ ngày càng to dần, nếu code ngay từ đầu viết còn khó đọc thì 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. 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ể:

Khi chia nhỏ class Sinhvien thì khi một người khác nhìn vào project cũng cảm thấy được sự khoa học và dễ hiểu, sau này dù nâng cấp nhiều thì cũng sẽ dễ dàng hơn, code ngắn cũng sẽ ít bug.

Việc tách bạch nhiệm vụ giữa các class khiến code trở nên rành mạch, dễ đọc, dễ bảo trì và mở rộng hơn rất nhiều. Sẽ dễ dàng để mở rộng ra các cách format mới sau này, hoặc cũng rất dễ để đáp ứng yêu cầu về nhiều cách xuất log hơn nữa khi chương trình được mở rộng.

Kết

Trong thực tế, việc áp dụng SRP còn phụ thuộc vào sự thay đổi của ứng dụng. Nếu ứng dụng thực sự thay đổi thì việc áp dụng SRP là cần thiết. Nếu ứng dụng không thực sự thay đổi mà chỉ là dự tính, thì việc áp dụng SRP có thể gây ra những phức tạp không cần thiết.

SRP là nguyên lý đơn giản dễ hiểu nhất, nhưng cũng khó áp dụng đúng nhất. Chúng ta thường nhóm các trách nhiệm lại với nhau một cách tự nhiên, nhưng trong lập trình, chúng cần tìm và tách riêng các trách nhiệm với nhau.