SOLID Principles - A Seminar Topic

Quấn vào vòng xoáy thị trường outsource nhiều, h là lúc em có thời gian ngồi nhìn lại những gì mình đã làm và nhận ra: À, mình cũng đã code theo nguyên tắc solid đấy chứ :)

Qua buổi chia sẻ cùng ae wecommit thì em đã tóm tắt được các ý chính, có thể có sai sót, mong được mọi người góp ý giúp em xây dựng bài viết hoàn chỉnh

• Author: Su - Linh Khuất ++ Huy, anh Kiên, anh Văn, anh Sơn, anh Nhật cùng các member tham gia, cảm ơn mọi người đã cùng góp ý để buổi thảo luận và chia sẻ thành công và ý nghĩa, em không thể làm điều này một mình nếu không có mn giúp đỡ 🙆‍♂️

Tóm tắt lại S.O.L.I.D:

• Solid là các nguyên tắc xoay quanh entities ( classes, funtions, module) được sinh ra nhằm giúp viết code được sạch đẹp, dễ bảo trì, có hệ thống hơn. Nói chung là theo 1 template thống nhất.

• Trong bài viết mình sẽ dùng từ thực thể - điều này áp dụng cho nhiều loại, có thể là Class, có thể là Function, có thể là modules, và hơn thế nữa.

• S.O.L.I.D được chia làm 5 nguyên tắc, với mục tiêu giúp code cứng ( như tên gọi ) ( có thể hiểu là code một cách hệ thống, thông minh, dễ hiểu).

• S trong solid có nghĩa là Single Responsibility Principles, nguyên tắc này có nghĩa: một lớp/function chỉ nên chịu một trách nhiệm duy nhất.

  • Ví dụ: Trong một màn hình mình code, thay vì code một màn hình vào một file, mình sẽ xé nhỏ từng phần UI thành các func nhỏ chỉ chịu trách nhiệm cho một phần của nó.

    • Phần slider chỉnh sáng sẽ chỉ chịu trách nhiệm chỉnh sáng

    • Phần title sẽ chỉ chịu trách nhiệm cho việc hiển thị title.

• Nguyên tắc O tức là Open/Closed Principles tức là class hay function viết có thể sử dụng để thêm nhưng rất hạn chế cho việc chỉnh sửa hoặc thậm chí không thể chỉnh sửa.

  • Ví dụ: Mình có một hàm vẽ button common, thì mình sử dụng hàm đó, thêm các tính năng vào (tạo ra một button được cá nhân hoá dựa trên common) nhưng việc sửa common là cực kỳ hạn chế vì nó ảnh hưởng tới rất nhiều phần khác đang sử dụng.

( cái này làm mình nhớ đến một ông trong cty với biệt danh HCommonlist :)) )

• Nguyên tắc L tức là Liskov Substitution Principles: Nguyên tắc này nói về việc một class con có thể thay đổi class của cha mà không làm ảnh hưởng đến tính đúng đắn của chương trình.

  • Ví dụ: các entities có chung nhất một vài đặc điểm, khi gọi nó dẫu dù là gọi cha hay gọi con thì nó đều không đổi, mình sẽ gọi nó là liskov.

  • Hình vuông hay hình khối thì đều có cạnh, thì jhi mình muốn gọi đến cạnh, thì mình có thể sử dụng hình vuông hay khối đều có tác dụng như nhau.

• Nguyên tắc I tức là Interface segration - với nội dung là chia nhỏ interface đúng mục đích để tránh việc phải gọi đến những hàm không cần thiết trong quá trình phát triển ứng dụng

  • Ví dụ: Khi mình phát triển, mình sẽ viết từng chức năng thành từng interface để tự do hơn trong việc thêm những tính năng mình muốn cho thực thể của mình mà không bị rằng buộc từ việc kế thừa.

  • Xe tăng được kế thừa từ xe, mình muốn có thêm tính năng bắn → mình có thể tự thêm tính năng đó vào :D

• Nguyên tắc cuối D - Dependency Inversion ( đảo ngược phụ thuộc) nói rằng module cấp cao ( high- level design) không nên phụ thuộc vào module cấp thấp.( Low - level)

  • Ví dụ: Khách hàng muốn có một sản phẩm, thì thay vì phải quản lý đội dev, nói chuyện trực tiếp, họ ký hợp đồng và nói chuyện qua anh Huy, anh Huy sẽ chịu trách nhiệm quản lý đội dev và trả khách hàng sản phẩm.

→ như vậy, khách hàng sẽ ít phụ thuộc vào đội dev nhất có thể mà vẫn có đầu ra là sản phẩm họ mong muốn. Ở đây, anh Huy và khách hàng - người gọi tới là High Level, còn đội dev là Low level chịu trách nhiệm phát triển và trả ra sản phẩm.

Ngoài ra:

• Phân biệt Single Responsibility Principles và Singleton: 1 cái là nguyên tắc code tối ưu 1 trách nhiệm và 1 cái là mẫu thiết kế để chỉ tạo và sử dụng 1 instance/ biến duy nhất xuyên suốt vòng đời của ứng dụng.

• Phân biệt Dependency Inversion và Dependency Injection: cũng vậy, 1 cái là nguyên tắc code giấu đi phần triển khai, chỉ cần đưa ra kết quả, 1 cái là mẫu thiết kế dùng để tiêm 1 thành phần tới function/ class nào cần nó.

• Không phải lúc nào cũng chọn Solid: tùy kiểu dự án - tùy lựa chọn:

  • Dự án đang chạy, code đang mượt → không cần thiết đập đi một thành phần rồi code nó theo nguyên tắc, cái nào đang chạy, thì follow theo luồng của nó thôi.

  • Dự án có thời gian ngắn → cứ thế triển khai vào một file nếu quy mô không to, không cần thiết phải thiết kế với dự án như vậy.

  • Solid sẽ thích hợp với dự án đi đường dài và nhiều người code.

22.03.25