SOLID – Nguyên tắc 1: Đơn nhiệm – Single Responsibility principle (SRP)
Bài viết gốc được đăng tải tại Vũ Công Tấn Tài
Chúng ta ắt hẳn đều đã có kiến thức về lập trình hướng đối tượng, nhưng việc vận dụng nó cách thuần thục và hợp lí thì không phải ai cũng biết. SOLID xuất hiện như là một trong những định hướng giúp các developer thiết kế hệ thống và phát triển phần mềm chất lượng hơn: code chạy tốt và trong sáng, dễ dàng mở rộng, dễ bảo trì trong tương lai, … SOLID là một trong những nguyên lí phát triển phần mềm sẽ được hỏi trong hầu hết các buổi phỏng vấn việc làm, nó cũng là nguyên lí mà tất cả các dev chúng ta nên biết và áp dụng nếu muốn cải thiện kĩ năng của bản thân. SOLID gồm 5 nguyên lí chính:
- Single Responsibility principle.
- Open-Closed principle.
- Liskov substitution principle.
- Interface segregation principle.
- Dependency inversion principle.
Bạn có thể tìm hiểu tổng quan về SOLID ở bài viết này. Trong bài này, mình sẽ đi sâu phân tích nguyên lí đầu tiên: Đơn nhiệm – Single responsibility principle (SRP). Bắt đầu nào!
Nguyên tắc thứ nhất nói gì
Phát biểu: Mỗi lớp chỉ nên chịu trách nhiệm về một nhiệm vụ cụ thể nào đó mà thôi.
Nguyên tắc này nói về việc: đơn nhiệm. Để hình dung một cách đơn giản, nếu bạn là một người phát triển phần mềm, thì bạn nên tập trung vào việc viết code và các vấn đề liên quan đến phần mềm, các việc lặt vặt như lau dọn văn phòng, đóng mở cửa văn phòng .v.v.. thì hãy để cho người khác làm ( ví dụ như công ty sẽ thuê người lao công để làm các việc này). Phân công công việc theo chuyên môn như thế vừa giúp bạn tập trung vào công việc để đạt được hiệu quả cao, vừa giúp văn phòng sạch sẽ hơn (vì người lao công sẽ lau dọn sạch hơn bạn ^^).
Nguyên lí này không chỉ áp dụng cho lĩnh vực IT và cho hầu hết mọi điều trong cuộc sống: mọi thứ chỉ nên tập trung vào chuyên môn của mình, nếu bạn ôm đồm quá nhiều việc một lúc thì kết quả đạt được sẽ không cao. Tấm hình sau minh hoạ cho việc này:
Hãy thử xem xét, với quỹ thời gian có hạn trong ngày, một mình bạn vừa phải làm công việc chính để có thu nhập nuôi gia đình, vừa phải lo chăm sóc con nhỏ, cho con bú … lại phải nấu nướng, giặt giũ, chăm vườn, tưới cây, … khi đó mặc dù có thể làm được nhiều việc một lúc, nhưng khả năng cao là bạn sẽ chẳng hoàn thành được tốt việc nào cả.
Nếu muốn các công việc đều được hoàn thành với hiệu suất cao, hãy thử chia nhỏ công việc ra và giao cho những thành viên khác trong nhà. Bạn tập trung đi làm kiếm tiền, quần áo dùng máy giặt để giặt, vườn cây thì thuê nhân viên vệ sinh dọn dẹp và chăm sóc, … Như vậy chắc chắc các công việc khác nhau đều được hoàn thành với một hiệu quả tối đa.
Áp dụng trong lập trình như thế nào?
Trong phần mềm cũng vậy, khi bạn thiết kế một phần mềm, để 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 lớp 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 lớp, thì nên tách đoạn code đó ra một lớp xử lí khác.
Hãy xem một ví dụ sau, chúng ta có một lớp học sinh với các hàm đơn giản như lấy thông tin học sinh, nộp đơn học bổng, …
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
class Student{ private string name; private int age; string getStudentInfoJson() { return json_encode( array(name, age) ); } string getStudentInfoHtml() { return "<span> Name: " + name + ", age: " + age + "</span>"; } int applyForScholarship() { try { // Trying to apply for scholarship } catch { //write error to log file system.Out.print("Error_log.txt", "Error getting scholarship!"); } }} |
Nếu thiết kế lớp học sinh như vậy thì đã ổn chưa nhỉ?
Tất nhiên, đoạn code trên có thể chạy đúng yêu cầu của phần mềm. Thế nhưng! Dường như lớp Student đang ôm đồm quá nhiều việc: cung cấp thông tin cá nhân, định dạng cấu trúc của thông tin cá nhân, ghi log, apply xin học bổng ..v.v.. Điều này vi phạm quy tắc đơn nhiệm. Về mặt logic xử lí, có một số câu hỏi mà chúng ta có thể thắc mắc: học sinh thì có nhiệm vụ gì mà phải đi định dạng dữ liệu nhỉ? Sau này nếu muốn định dạng ghi log từ file thành DB thì như thế nào? Đổi định dạng format thông tin log thì sẽ sửa code làm sao? …
Áp dụng quy tắc đơn nhiệm của SOLID, sẽ tốt hơn nếu ta xây dựng thêm các lớp riêng biệt làm nhiệm vụ format data và ghi log. Chúng ta sẽ thực hiện refactor lại đoạn code ở trên, code mới trông sẽ như thế này:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
class Student{ private string name; private int age; string getName() { return name; } int getName() { return age; } bool applyForScholarship() { try { // do something here } catch { ExportLog log_control = new ExportLog(); log_control.exportLogToFile( "error_log.txt", "Error getting scholarship"); } }}class Formatter(){ string formatInfoJson(string name, int age) { return json_encode( array( name, age ) ); } string getStudentInfoHtml(string name, int age) { return "<span> Name: " + name + ", age: " + age + "</span>"; }}class ExportLog{ void exportLogToFile(string filename, string error) { //write error to log file system.Out.print( filename, error ); }} |
Như bạn thấy đó, việc tách bạch nhiệm vụ giữa các lớp 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 luận
Nguyên lí này trông có vẻ đơn giản, nhưng thực ra cần rất nhiều thời gian và luyện tập để có thể sử dụng thành thục nguyên lý này. Tuy nhiên cũng không nên vội vàng, hãy để thời gian để bạn “ngấm” được ý nghĩa thực sự của nguyên lý này.
Về mặt kĩ thuật mà nói, đoạn code trên vẫn còn có thể trở nên tốt hơn nữa nếu chúng ta áp dụng các kĩ thuật khác trong SOLID, nhưng mình chỉ đang muốn nhấn mạnh ở đây tính đơn nhiệm của chương trình.
Chúng ta mới chỉ áp dụng một quy tắc đầu tiên của SOLID – quy tắc đơn nhiệm – vào thiết kế phần mềm thì code đã trở nên trong sáng và hữu dụng hơn rất nhiều. Có thể dễ dàng hình dung được, nếu các anh em developer chúng ta đều nắm vững và áp dụng các quy tắc này, thì phần mềm của chúng ta sẽ tốt lên rất nhiều.
Bài viết gốc được đăng tải tại nhungdongcodevui.com
Có thể bạn quan tâm:
- SOLID là gì? Áp dụng SOLID để trở thành lập trình viên giỏi
- Principle thiết kế của các sản phẩm nổi tiếng
- Software engineer phát triển bản thân như thế nào?
Xem thêm các việc làm Developer hấp dẫn tại Station D
