Programming
Created Thursday 14 July 2016
Mô hình RAII: (Resource Acquisition Is Initialisation) - do Misha giới thiệu khi ăn trưa ngày 14/7/2016 ở IMTEK
Đây là một châm ngôn (idiom) để lập trình, nhằm quản lý việc sử dụng tài nguyên bộ nhớ tốt hơn. Với RAII, ngay từ khi tạo lập một biến/đối tượng, người viết chương trình đã định sẵn việc thu lại bộ nhớ cấp phát cho biến đó sau khi xóa bỏ nó. Cơ chế của RAII tốt hơn Java ở chỗ tuy Java có tự động thu dọn rác (với garbage collector), nhưng ta không biết được việc dọn rác được thực hiện vào lúc nào. Việc lập trình theo nguyên tắc RAII giúp ấn định thời điểm thu dọn rác, và cũng tốn ít dòng lệnh hơn (không cần lo việc dọn rác vào thời điểm sau khi không dùng biến đó nữa).
Tham khảo: https://www.hackcraft.net/raii/
18.4.2017 (Facebook):
Nghia Minh Le: Design Patten không nên học nhiều, nó chỉ là cookbook, kiểu chiêu thức thôi. Muốn giỏi phải luyện thật nhiều nguyên lý SOLID. Tự em sẽ suy ra pattern. Chăm chăm học pattern nó sẽ giống như thiếu gốc dễ. Biểu hiện rõ nhất: là em học nhiều nhưng nhớ được bao nhiêu và dùng được bao nhiêu. Anh trước vô cùng hứng thú với design pattern từ năm 2, đi dạy người khác, nhưng rồi chả nhớ gì và chả dùng mấy. Chỉ khi anh hiểu bản chất, thì pattern nó mới ngấm vào trong máu được.
Duc Nguyen Nghia Minh Le anh có recomend sách hay blog nào về SOLID không anh?
Nghia Minh Le Chả có mấy, cái đó ngắn lắm, đọc tí hết, nhưgn vận dụng thì vô biên. Chịu khó đọc cuốn clean code, tìm hiểu về TDD để xây dựng thói quen liên tục refactor code, mỗi lần refactor đưa nguyên lý SOLID ra vận dụng để improve code mình lên. Rồi trình sự tự lên thôi.
---
Design pattern xuất phát từ object-oriented
OOP xuất phát từ mô phỏng, ngôn ngữ đầu tiên gọi là Simulate (xem ở VP Labs)
Vấn đề của programming design là build model
Procedure programming không scale up được, nên cần dùng OOP để scale.
Đầu tiên có abstract data types, dạng record, còn các hàm vẫn nằm riêng.
Bước thứ hai là thêm các hàm vào abstract.
Lúc đầu, cơ chế để làm ra object là dựa trên class, class giống như template để tạo khuôn cho objects. Mechanism đó là implementation của object-oriented, chứ không phải là object.
-> pragmatic programming: dựa trên các cách implementation
1 trong các mistakes đầu tiên của lập trình là expose data type ra -> các hàm khác bị phụ thuộc vào data type cụ thể, thành ra sau này khó thay đổi.
Do class và object bị lẫn lộn nhiều quá, nên người ta đưa ra design patterns để hạn chế confusion.
"Design patterns" trong sách của tác giả từ Microsoft, lúc đầu được xem như thần thánh, ai cũng dùng, nhưng càng dùng sẽ càng làm rối design.
Cái design patterns đúng đắn là phải từ requirement analysis đến cách thiết kế architecture.
Cách làm của Quang:
- Từ requirements, lập các use cases, rồi cần các objects. Từ objects mới thiết kế ra các classes để implement. (chứ không đi từ class trước)
- Nói theo DCI, phải phân ra được 2 loại: data và hàm để expose và thay đổi data, ngoài ra có connections. DCI tách 3 lại object đó lại với nhau.
Mô hình OOP là dựa trên mindset các objects như team that is organic organized.
- Nếu làm connection ở class level, thì vì connection nằm trong class nên các classes nó phức tạp. Vì nó có thể phức tạp nên người ta đẻ ra design patterns để deal với accidental complexity (complexity đẻ ra do cách làm, chứ không phải không tránh được như essential complexity) trong class.
Ví dụ của Quang:
Steps là thể hiện algorithms
Mọi vấn đề xoay xung quanh dependency.
Interaction diagram và sequence diagram là quan trọng nhất, nó thể hiện algorithm.