Contents
Chào bạn, bài hôm nay sẽ tản mạn một chút về nghề dev này. Và bài này sẽ không dạy đời dạy người mà chỉ nói về 1 nguyên tắc để trở thành Dev cứng.
Dev cứng là gì?
Cứng==SOLID
SOLID là nguyên tắc có từ ngàn đời này để cho dev/coder/anh lập trình viên … tuân theo như một kim chỉ nam trong nghề. Mặc dù còn có rất nhiều nguyên tắt khác.
- S: Single responsibility principle
- O: Open/closed principle
- L: Liskov substitution principle
- I: Interface segregation principle
- D: Dependency inversion principle
Mục đích nó đến với trái đất này là gì?
Hiểu đơn giản thì S.O.L.I.D làm cho source code đẹp hơn và dev/coder yêu đời hơn.
Vậy phân tích tụi nó một chút nha.
1. Single responsibility principle
Nguyên lý đầu tiên, tương ứng với chữ S trong SOLID. Nội dung nguyên lý:
Một class chỉ nên giữ 1 trách nhiệm duy nhất (Chỉ có thể sửa đổi class với 1 lý do duy nhất).
Giải thích thì:
Sống đơn giản cho đời thanh thản.
2. Open/closed principle
Nguyên lý thứ hai, tương ứng với chữ O trong SOLID. Nội dung nguyên lý:
Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó (open for extension but closed for modification).
Giải thích thì:
Code cũ đừng thay đổi làm gì, nên viết thêm phần mở rộng cho nó.
3. Liskov Substitution Principle
Nguyên lý thứ ba, tương ứng với chữ L trong SOLID. Nội dung nguyên lý:
Trong một chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình.
Giải thích thì:
Khó hiểu thấy bà, nói chung dành cho các thanh niên thích ép kiểu thì hiệu quả hơn. nhưng đừng ép kiểu ngược.
Ví dụ mượn tạm của người ta vậy:
Hãy tưởng tượng bạn có 1 class cha tên Vịt. Các class VịtBầu, VịtXiêm có thể kế thừa class này, chương trình chạy bình thường. Tuy nhiên nếu ta viết class VịtChạyPin, cần pin mới chạy được. Khi class này kế thừa class Vịt, vì không có pin không chạy được, sẽ gây lỗi. Đó là 1 trường hợp vi phạm nguyên lý này.
4. Interface Segregation Principle
Nguyên lý thứ tư, tương ứng với chữ I trong SOLID. Nội dung nguyên lý:
Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể.
Giải thích thì:
Các thanh niên thích khổ dâm thì nên chú ý. Đừng cố ôm quá nhiều việc vào 1 class. Nên tách ra và học cách xây dựng các class rồi hành thực hiện. Các anh lead phải luyện tập để còn chia viêc cho nhiều người nhưng vẫn control được mọi thứ.
5. Dependency inversion principle
Nguyên lý cuối cùng, tương ứng với chữ D trong SOLID. Nội dung nguyên lý:
1. Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. Cả 2 nên phụ thuộc vào abstraction.
2. Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại.
( Các class giao tiếp với nhau thông qua interface, không phải thông qua implementation.)
Giải thích thì:
Mua 1 em iPhone bên Mẽo, về Việt Nam vẫn cắm sạc được như thường. Hay bỏ cái sim nước khác vào em iphone bản quốc tế thì vẫn gọi ầm ầm được. Hay ra tiệm mua cái dây apple watch của Tàu khựa thì vẫn bỏ gắn vào đẹp như mới cho em Apple Watch….
Kết luận
Các phân tích và giải thích trên mang lại tác dụng chính là giúp bạn cảnh tĩnh trong quá trình code mà thôi. Chi tiết việc cài đặt & viết code thì bạn có thể tham khảo nhiều nguồn trên Google.
Ngoài ra, bản thân mình cũng không nên bó buộc quá nhiều vào nhưng nguyên tắc. Các bạn dev/coder mới thì cứ đừng theo khuôn khổ nào hết, mà hãy sáng tạo. Khi kết quả cuối cùng đúng rồi thì bắt đầu lại việc đọc code của mình và đưa những nguyên tắt cơ bản trên áp dụng vào code.
Chúc bạn thành công!
Related Posts:
1 comment
Leave a Reply
Donate – Buy me a coffee!
