SOLID Principles #1: Single Responsibility Principle

Có nhiều người đã biết đến nguyên tắc SOLID qua nhiều bài viết trên viblo như: đây hoặc đây. Nhưng trong series này mình sẽ giúp các bạn hiểu rõ hơn về từng yếu tố trong nguyên lý SOLID, đừng bỏ lỡ nhé! Yếu tố đầu tiên mình đề cập trong series này là: Single responsibility principle - Nguyên tắc đơn trách nhiệm.

"Một class (object) có một và chỉ một trách nhiệm duy nhất"

Để có thể giúp mọi người hiểu rõ điều này hơn, thì chúng ta bắt đầu giải thích rõ hơn: làm thể nào để định nghĩa class (object) chỉ có một trách nhiệm duy nhất?

Chúng ta hãy xem xét câu sau: "Không nên có nhiều hơn một lý do để sửa đổi (viết lại) một class ”. Mình sẽ cố gắng giải thích lý do này.

Ta có ví dụ sau: Giả sử chúng tôi muốn tạo 1 user. Điều đầu tiên chúng ta cần thực hiện đó là validate dữ liệu. Mình tạo một service object để thực hiện điều đó như sau:

Class trên có chức năng validate những user input rồi sau đó thực thi dữ liệu. nhưng chúng ta thấy, validate và thực thi dữ liệu là 2 hoạt động tách biệt. Trước khi ta tiến hành sửa chữa, cải thiện giải pháp này cần phải làm rõ tại sao giải pháp đó không tốt.

Trước hết, hai quy trình này được kết hợp chặt chẽ, Không có cách nào dễ dàng để tái sử dụng một trong số chúng một cách riêng biệt.

Nhưng để class như vậy sẽ có khả năng xuất hiện những sai lầm tiềm tàng đồng thời việc kiểm tra lại cũng sẽ khó khăn hơn.

Chính vì vậy chúng ta cần chuyển code validate sang 1 class khác:

Bây giờ, chúng ta có hai lớp, mỗi lớp chỉ có một trách nhiệm duy nhất.

Lớp đầu tiên xử lý dữ liệu, lớp thứ hai thực hiện validate dữ liệu. Nếu chúng ta phải thay đổi các quy tắc validate, chúng ta chỉ cần sửa trong lớp UserValidation. Tương tự như vậy với việc xử lý dữ liệu, chúng ta không phải thay đổi lớp UserCreateService. Và chúng ta có thể dễ dàng tái sử dụng lại các lớp này.

Ngoài ra thực thi như vậy còn mang lại lợi thế trong việc test, chúng ta sẽ có thể test riêng biệt cách lớp khác nhau chứ không cần gộp lại như trước, sẽ mất khá nhiều logic.

Bạn có thể đã nghe nói về Domain Driven Development (DDD). Khái niệm này liên quan đến các thuật ngữ khác như: information expert hoặc rich domain model. với rich domain model, khái niệm này giả định rằng chúng ta giữ tất cả hành vi được kết nối chặt chẽ cho mô hình cụ thể trong model. Vì vậy, ta giữ dữ liệu & logic hoạt động ở cùng một vị trí. Nghe như là chúng ta đang nói về OOP đó