S O L I D

Tưởng dễ mà lại rất khó!

Mặc dù đã có rất nhiều bài viết ở các blog, các page, các group khác nhưng mình vẫn chưa thấy thỏa đáng (có thể là các bạn chỉ đi dịch lại từ các bài viết tiếng anh), nên mình sẽ viết 1 loạt bài về vấn đề này dựa trên kinh nghiệm thực chiến của mình.

S.O.L.I.D là gì

S.O.L.I.D là bộ quy tắc được phát triển bởi các lập trình viên nhiều kinh nghiệm, và đặc biệt là các lập trình viên đi phát triển thư viện hay Framework. Nó là những gợi ý các tổ chức source code sao cho khoa học, dễ hiểu và dễ mở rộng về sau này, bạn có thể áp dụng nó hay không đó tùy thuộc vào quan điểm của bạn, nhưng mình nghĩ là nên áp dụng, 🙂.

S.O.L.I.D có gì?

S: Single-responsibility principle - Mỗi hàm hãy chỉ nên phụ trách xử lý một vấn đề duy nhất, mỗi lớp chỉ nên chứa các hàm có sự liên quan với nhau O: Open–closed principle - Nên hạn chế thay đổi với các hàm, lớp đã chạy ổn định và tìm cách mở rộng lớp hoặc tạo hàm mới cần bổ sung tính năng L: Liskov substitution principle - Một lớp, một tham số của hàm có thể thay thế lớp cài đặt mà không cần thay đổi source code hoặc không làm ảnh hưởng tới tính đúng đắn của chương trình đang chạy, ý nói rằng hãy chăm chỉ dùng interface đi, đừng có lúc nào cũng chỉ dùng lớp cài đặt, 🙂, ví dụ hàm để thanh toán Order.pay() I: Interface segregation principle- Hãy chia 1 interface rất nhiều hàm ra thành nhiều các interface chứa các hàm có liên quan mật thiết với nhau, vì 1 interface có thể extends nhiều interface khác mà, đúng không? D: Dependency inversion principle - Khi sử dụng, hãy phụ thuộc vào các interface và các lớp abtract thay vì lớp cài đặt để sau này chỉ cần thay đổi lớp cài đặt thôi mà không cần cập nhật lớp đang sử dụng, ví dụ lớp BookService nên phụ thuộc vào interface BookRepository chứ không nên phụ thuộc vào BookRepositoyForMySQLImpl vì sau này chúng ta muốn dùng MongoDB chẳng hạn chúng ta chỉ cần tạo cài đặt mới cho BookRepository là BookRepositoyForMongoDBImpl thôi, còn lớp BookService vẫn giữ nguyên

S.O.L.I.D cần gì

Cái mà S.O.L.I.D cần nhất đó chính là design pattern, theo kinh nghiệm của mình thì có sử dụng design pattern như sau:

Single-responsibility principle: Command, Composite, Strategy, Chain of Responsibility design pattern.
Open–closed principle: Command, Composite, Strategy, Chain of Responsibility, Decorator, Proxy design pattern, gần như nguyên tắc này phải vận dùng hết tất cả các design pattern.
Liskov substitution principle: Template method, Proxy, Decorate, Bridge design pattern
Interface segregation principle: Adapter, Bridge design pattern
Dependency inversion: Singleton, Composite design pattern

Và cuối cùng, cái S.O.L.I.D cần đó chính là kinh nghiệm. Bạn đừng kì vọng rằng ngay sau khi đọc xong S.O.L.I.D thì bạn sẽ có thể áp dụng được ngay. Nó thực sự rất khó đấy. Thời gian đầu sẽ thực sự mung lung, cái cảm giác cứ viết 1 dòng lại cảm thấy có gì đó chưa đúng. Hậu quả là tiến độ dự án sẽ bị chậm, dẫn đến việc bạn sẽ chán nản và bỏ cuộc, chính mình cũng đã trải qua thời gian khó khăn này, nhưng may mắn mình đã sống khoẻ. Ở thời điểm hiện tại kinh nghiệm sẽ chỉ cho mình biết trong trường hợp nào thì nên làm gì, dùng kỹ thuật lập trình gì, design pattern gì, mình hy vọng chúng ta sẽ đều có khả năng như vậy.