Trên con đường trở thành một developer “xịn” thì việc biết và áp dụng thành thạo S.O.L.I.D là một trong những điều kiện tiên quyết. Nó giúp ta định hình lại tư duy code rất nhiều như việc tổ chắc code, phân chia vai trò và tương tác giữa các module, class, method… Từ đó giúp code dễ đọc, dễ hiểu, dễ maintaince hơn. Nó giúp ta viết các Testable Code để thực hiện Unit Code. Nó là nguyên lý được áp dụng vào IoC/DI. Và còn nhiều ứng dụng khác. Nhưng quan trọng nó sẽ giúp bạn được tăng lương hoặc phỏng vấn tốt hơn đó 😸.
Introduction to S.O.L.I.D principles
S.O.L.I.D là tập hợp 5 nguyên lý định hướng thiết kế và code trong lập trình hướng đối tượng (OOP). Được đưa ra bởi Bob Martin (cha đẻ của “thánh kinh” Clean Code[1]) và Michael Feathers. 5 nguyên lý trong S.O.L.I.D bao gồm:
- Single responsibility priciple
- Open/Closed principle
- Liskov substitution principe
- Interface segregation principle
- Dependency inversion principle
→ S.O.L.I.D là cách chơi chữ từ 5 chữ cái đầu cửa các nguyên lý, cũng khá thú vị phải không ;)).
Single responsibility priciple
A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
— Wikipedia
Nguyên tắt này tuyên bố một class chỉ nên có một trách nhiệm và việc thay đổi nó cũng chỉ vì đúng trách nhiệm đó thôi. Nguyên lý này sẽ rất hữu dụng đối với những dự án lớn nơi mà chỉ cần một thay đổi nhỏ có thể ảnh hưởng tới toàn bộ chương trình.
Open/Closed principle
Software entities … should be open for extension, but closed for modification.
— Wikipedia
Nguyên lý này khuyên chúng ta viết thêm một class mới kế thừa từ class cũ để mở rộng tính năng thay vì sửa class cũ. Nguyên lý này rất hữu ích với những dự án cũ khi mà việc thay đổi có thể ảnh hưởng tới những chức năng hiện tại.
Liskov substitution principe
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
— Wikipedia
Các object của class con có thể thay thế cho class cha mà không làm thay đổi tính đúng đắng của chương trình. Nguyên lý này giúp đảm bảo tính đúng đắn và ổn định cho chương trình. Đây là nguyên lý rất dễ bị vi phạm nếu developer không chú ý và có thể dẫn đến những hậu quả to lớn.
Interface segregation principle
Many client-specific interfaces are better than one general-purpose interface.
— Wikipedia
Nguyên lý này khá đơn giản khi yêu cầu ta nên chia nhỏ các interface ra sẽ tốt hơn một interface có nhiều mục đích. Lý do của việc này nhằm tránh dư thừa những method cần phải implement khi kế thừa interface nhiều mục đích ở trên.
Dependency inversion principle
One should “depend upon abstractions, [not] concretions”.
— Wikipedia
một định nghĩa dễ hiểu hơn ;))
Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.
Chắc đọc tới đây vẫn chưa hiểu đâu. Đây là nguyên lý khó hiểu nhất vì cũng trừu tượng nhất mà;)).
Mình lấy ví dụ việc lái xe đạp và lái máy bay (ý mình là nghĩa đen nhé 😽). Về cơ bản hai hành động này rất khác nhau. Nhưng nếu ta trừu tượng hóa thành các hành động đơn giản hơn như: bẻ lái, tăng/giảm tốc, thắng thì lúc này 2 hành động trên là tương tự nhau và cụ thể hóa của bẻ lái, tăng/giảm tốc, thắng là khác nhau.
Hãy xem thêm bài Inversion of Control and Dependency Injection để thấy được IOC/DI cũng là một phần của việc áp dụng nguyên lý này nha các bạn.
Kết: S.O.L.I.D là khái niệm khó, việc hiểu nó cũng là một vấn đề với người mới nhưng S.O.L.I.D chỉ thật sự có ý nghĩa nếu được áp dụng vào dự án. Và tin mình đi một khi đã áp dụng được S.O.L.I.D vào dự án thì công việc code và maintaince và test sẽ trở nên dễ dàng. Bài viết này chỉ dừng lại ở mức khái niệm. Việc áp nó như thể nào sẽ có một loạt bài nói riêng nhé.
Cảm ơn các bạn đã đọc tới đây và mong các bạn sẽ thích bài viết này.