SOLID Principles: Single Responsibility

SOLID là gì?

Chắc hẳn nếu ai đã từng học hướng đối tượng thì đều biết đến 4 khái niệm cơ bản

• Abstraction (Tính trừu tượng)
• Encapsulation (Tính đóng gói)
• Inheritance (Tính kế thừa)
• Polymophirsm (Tính đa hình)
  

Vậy thiết kế hướng đối tượng sẽ như thế nào?
Hôm nay mình sẽ giới thiệu với các bạn 5 nguyên tắc thiết kế hướng đội tượng được gọi là SOLID
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 developer viết ra những đoạn code dễ đọc, dễ hiểu, dễ maintain
Ở bài này chúng ta sẽ cùng tìm hiểu nguyên tắc đầu tiên Single Responsibility tương đương với chữ S

Single Responsibility

Một class chỉ nên giữ một trách nhiệm duy nhất.

Nếu một class có nhiều hơn 1 lý do để thay đổi thì có nghĩa là nó có nhiều hơn 1 trách nhiệm.
Như hình bên, ta có 1 con dao đa năng, nó rất cồng kềnh và khi một bộ phận bị hỏng ta phải thảo cả con dao ra và sửa chữa.
Công việc bảo trì trở nên phức tạp và gây ảnh hưởng đến chức năng khác

Ta cùng theo dõi ví dụ dưới đây

class EmailHelper
{
    public void Validate(string email)
    {
        // some validation logic
    }
 
    public void Send(string email, string message)
    {
        // some sending logic
    }
}

Class trên làm gì? Câu trả lời là Class trên giúp thao tác với địa chỉ email.
Nhưng nó đã vi phạm nguyên tắc S, Class này có nhiều hơn 1 trách nhiệm. Vừa validate lại vừa gửi email.
Vậy ta nên thiết kế như thế nào để nó phù hợp với nguyên tắc Single Responsibility?
Hãy theo dõi ví dụ dưới đây.

class EmailValidator
{
    public void Validate(string email)
    {
        // some validation logic
    }
}
 
class EmailSender
{
    public void Send(string email, string message)
    {
        // some sending logic
    }
}

Rất đơn giản, ta chỉ cần tách 2 class mỗi class 1 trách nhiệm là xong. Sau này mở rộng ta chỉ cần thêm class khác.
Nếu cần chỉnh sửa gì thì với mỗi class ta chỉ thay đổi vì 1 lý do duy nhất.

Kết luận

Đây chỉ là nguyên tắc, trong thực tế các bạn sẽ thấy có những helper hay util class vi phạm nguyên tắc này
Thậm chí sẽ có nhiều tranh cãi xoay quanh việc áp dụng nguyên tắc này.
Nguyên tắc chỉ là nguyên tắc. Hãy xem nó như 1 hướng dẫn chứ không phải bắt buộc.
Hãy sử dụng nó một cách hợp lý và biết khi nào cần khi nào không.
Mời các bạn đóng đọc tiếp nguyên tắc thứ 2 Open/Closed Principle
Chúc các bạn thành công.