Nếu những viên gạch không được làm tốt, thì kiến trúc của tòa nhà có tốt đến đâu cũng không có nghĩa lý gì. Nhưng cũng có thể tạo ra một đống lộn xộn dù cho những viên gạch có tốt đến đâu.

“Trong tất cả các loại nguyên lý lập trình, mình thích nhất là SOLID, vì SOLID giúp mình ….. trong lập trình hướng đối tượng….” Văn mẫu nghe quen quá anh em nhỉ? 😄😄😄. Hẳn là nhiều anh em khi tiếp cận với các nguyên lý lập trình cũng đều giống mình, tìm kiếm một vài bài viết trên google (topdev, toidicodedao, …), hoặc sang chảnh hơn thì ta có thể lên medium, dev.to, … Nhưng hầu hết các bài viết mình đã đọc hoặc được tiếp cận thì đều gắn liền SOLID với lập trình hướng đối tượng (OOP), họ đều dạy ta cách bố trí các class như nào, cách viết các interface làm sao, và dù những điều này đúng nhưng là chưa đủ. Và sau khi được tiếp cận với một tài liệu(do một người anh nào đó chia sẻ) có thể được coi là của cha đẻ SOLID, mình đã có cái nhìn khác về SOLID. Bài viết hôm nay mình sẽ chia sẻ tổng quan về SOLID cũng như cách tiếp cận mà mình cho là đúng đắn hơn với nguyên lý lập trình này.

1. Về lịch sử hình thành.

• Cuối những năm 1980, trong khi tranh luận với những người khác về các nguyên tắc thiết kế phần mềm, Uncle Bob đã tổng hợp và đưa ra một số nguyên tắc.
• Qua nhiều năm, các nguyên tắc đã có thay đổi và điều chỉnh (loại bỏ, gộp lại, bổ sung). Đến đầu những năm 2000, các nguyên lý đã ổn định tuy chưa có thứ tự như ngày nay.
• Khoảng năm 2004, Michael Feathers đề xuất thay đổi thứ tự để có được “SOLID” như ngày nay.

2. Vậy SOLID là gì?

• SOLID là những nguyên lý chỉ cho chúng ta cách sắp xếp các hàm và các cấu trúc dữ liệu vào các “lớp” và cách các “lớp” đó nên được kết nối với nhau như thế nào.
• Việc dùng từ các “lớp” khiến chúng ta thường gặp phải hiểu lầm rằng SOLID chỉ áp dụng cho phần mềm hướng đối tượng. Tuy nhiên một “lớp” ở đây chỉ đơn giản là một nhóm các hàm và dữ liệu được liên kết với nhau. Trong mọi hệ thống phần mềm thì đều có những nhóm như vậy dù có được gọi là lớp hay không, và các nguyên tắc SOLID áp dụng cho tất cả các nhóm như vậy.

3. SOLID để làm gì?

SOLID cung cấp các nguyên tắc để xây dựng các thành phần ở mức mid-level (module, component) mà đảm bảo được các tiêu chí:

• Đáp ứng được sự thay đổi.
• Dễ hiểu (don’t make me think).
• Các thành phần cơ bản có thể được sử dụng lại ở nhiều nơi trong phần mềm.

4. SOLID gồm những gì?

Như anh em đều đã biết, SOLID đại diện cho 5 nguyên tắc con:

• SRP: The Single Responsibility Principle.
  • Mỗi module chỉ có 1 và duy nhất 1 lý do để thay đổi.
• OCP: The Open-Closed Principle.
  • Hành vi của các hệ thống được thay đổi bằng cách thêm mã mới, chứ không phải là sửa lại mã cũ.
• LSP: The Liskov Substitution Principle.
  • Các bộ phận trong một phần mềm phải được xây dựng sao cho chúng tuân thủ theo các thỏa thuận chung, cho phép có thể thay thế bất kì phần nào của của phần mềm bằng các phần khác.
• ISP: The Interface Segregation Principle.
  • Phần mềm nên tránh phụ thuộc vào các thành phần mà nó không sử dụng.
• DIP: The Dependency Inversion Principle.
  • Mã nguồn cài đặt ở mức high-level policy không nên phụ thuộc vào mã nguồn được cài đặt ở mức chi tiết, mà thậm chí là ngược lại, mã nguồn chi tiết nên phụ thuộc vào các policy.

Trên đây mình đã đưa ra các khái niệm, lịch sử hình thành của SOLID, và các nguyên lý con dưới góc nhìn tổng quan hơn. Từ đó giúp có cái nhìn đúng đắn hơn về SOLID. Chi tiết các nguyên lý con mình sẽ chưa bàn đến trong phạm vi bài viết này. Anh em nào có hứng thú có thể tìm hiểu cùng mình và chia sẻ lại trong những bài viết tiếp theo nhé. Giờ thì xin phép anh em đi code đã, một số người anh tên H***, tên T****, tên Q**** đang ngó rồi 🥴🥴🥴.

BaND