Download to read offline
Design pattern [factory method]
- 1. Factory Method Design Patternin Action
- 2. Từ khóa “new” •Interface • Dễ ràng thêm các loại Pizza khác
- 3.
- 4. Chúng ta cầnthêm nhiều “new” • Một vài món cần bỏ đi • Một vài món mới cần thềm vào
- 5. The Open andClose Principle “Có thể thoải mái mở rộng 1 module, nhưng hạn chế sửa đổi bên trong module đó (open for extension but closed for modification)”
- 6. Factory • Chia nhỏvấn đề cần giải quyết • Sử dụng lại, tránh việc trùng lặp code
- 7. PizzaShop and Factory •Một client của BepViaHePizza
- 8. PizzaShop and Factory •PizzaShop và BepViaHePizza • Tính Flexible có còn? • Giải pháp là gì?
- 9. Một Interface choviệc khởi tạo? • Điều gì xảy ra khi HaNoiShop dùng BepSaiGon
- 11.
- 12.
- 13. Design Pattern • Intent •Motivation: • Applicability • Structure • Participants
- 14. Intent “Định nghĩa mộtinterface cho việc tạo object, nhưng để subclasses quyết định việc khởi tạo, Factory method cho phép một class trì hoãn việc khởi tạo cho subclasses” • Class • Interface • Object • Subclasses
- 15. Motivation • Sửa đổi:trách nhiệm của HaNoiShop, SaiGonShop class • Mở rộng: thêm mới DaNangShop
- 16. Applicability • Class khôngthể dự đoán các đối tượng và nó sẽ cần khởi tạo • Class muốn các subclasses của nó chỉ định các objects được khởi tạo • Classes giao quyền, trách nhiệm cho một trong các subclasses giúp đỡ đồng thời bản địa hóa kiến thức mà subclass đó được giao
- 17.
- 18. Participants • Product • ConcreatProduct •Creator • Concreator
- 19. Tham khảo • https://refactoring.guru •Head First Design Patterns: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates • Design Patterns: Elements of Reusable Object-Oriented Software: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Editor's Notes
- #5 datMuaPizza function vi phạm những nguyên tắc nào trong SOLID Principles? – Single Reposibility, Open and Close
- #7 Kiến thức về khởi tạo, quy trình được tách biệt Quy trinh phục vụ tại bàn và quy trinh giao hàng sử dụng shipper có thể khác nhau CreatePizza được sử dụng lại ở nhiều nơi
- #8 Vấn đề: Không chỉ có một BepViaHePizza DuyTanExpressPizza CauGiayExpressPizza NumberOneHamNghiPizza HanoiPizza HoChiMinhPizza
- #9 Chúng ta nhận thấy mỗi cửa hàng Pizza gắn chặt với danh mục Pizza mà nó phục vụ (BepViaHePizza) Danh mục Pizza thể hiện tính đặc thù: SaiGon thì thích vị ngọt, DaNang thì cay, HaNoi thì đậm đà
- #10 Người Hà nội không thích vị ngọt và ngược lại người SaiGon không thoải mái lắm với vị đậm đà Thoạt nhìn thì có vẻ flexible, nhưng tinh flexible này lại dẫn đến lỗi khi chạy chương trình (run-time) Chúng ta cần chú ý tới tính đặc thù chỉ có ở Hà Nội hoặc Sài Gòn Các shop cụ thể, HaNoiShop, SaiGonShop khi nhìn vào interface IPizzaCreator sẽ không thể thấy được thông tin mà đúng ra nó có trách nhiệm quản lý. => đừng bao giờ lặp lại sai lầm này! Nó sẽ dẫn tới nhiều lỗi tiềm ẩn cho chương trình của các bạn sau này
- #11 Tình huống thực tế chỉ ra rằng đừng làm điều đó Vậy chúng ta nên làm gì?
- #12 - Các bạn hãy nhìn vào sơ đồ này, hãy hình dung xem chúng ta sẽ code nó như thế nào?
- #13 Hướng dẫn sinh viên thực hiện code Đánh giá khả năng code từ việc trao đổi, thực hành trong quá trình code
- #14 Chúng ta sẽ cùng duyệt lại các đặc điểm chung của một Design Pattern và trong trượng hợp Factory Method này nó là gì?
- #15 Class: trong ví dụ trước thì PizzaShop chính là class đã trì hoãn việc khởi tạo các Objects (ở đây là các objects của các kiểu PhoMaiPizza, HaiSanPizza, …) Interface: Khi đọc trong các tài liệu về Factory Method, dễ bị nhầm lẫn với key word của java hoặc C#; Thực tế interface ở đây chính là hàm abstract taoPizza trong class PizzaShop. Object: là đối tượng được tạo ra khi chương trình hoạt động Subclasses: HaiNoiShop, SaiGonShop
- #16 Nhìn vào source code sẽ thấy nhiệm vụ HaNoiShop và SaiGonShop là quản lý thực đơn của chính shop đó (single responsibility principle) DaNangShop trong so sánh với HaNoiShop và SaiGonShop đó là sự khác biệt về khẩu vị hay chinh là danh sách các loại Pizza riêng của DaNangShop Chúng ta chỉ cần extends PizzaShop và thêm phần code miêu tả điều này => chỉ viết thêm code tương ứng với yêu cầu mới, không cần sửa đổi code đã viết Kiến thức đặc thù (sau này sẽ là requirement) ở mỗi shop (HaNoi, DaNang, SaiGon) được lưu giữ và đóng gói trong chính subclass đó.
- #18 - Các bạn hãy nhớ lại các thành phần trong ví dụ trước và ghép tương ứng với Product, ConcreateProduct, Creator, Concreator
- #19 Product: trong ví dụ trước đó là IPizza, có thể là interface hoặc abstract class trong java; Nó định nghĩa các đặc tính chung của các objects liên quan Cùng là Pizza thì đều có bước chuẩn bị, nướng, cắt, đóng gói ConcreatProduct: kế thừa hoặc cụ thể hóa các đặc tính được định nghĩa ở Product và quy định các đặc tinh riêng của nó Cùng là Pizza, Hải sản cần chuẩn bị nguyên liệu là hải sản, thời gian nướng sẽ ngắn hơn, … Creator: abstract class chứa một số thông tin chung tương ứng với Product, nhưng nó sẽ không thể dự đoán được cụ thể sẽ có những kiểu Product như thế nào nên nó sẽ định nghĩa một hàm abstract để trao lại quyền, đồng thời loại bớt thông tin mà nó cần quản lý Thông tin chung tương ứng với Product là: chuẩn bị => nướng => cắt => đóng gói: đảm bảo các shop cụ thể luôn thực hiện đủ 4 bước này Trì hoãn, giao lại, chia bớt phần tạo các ConcreatProduct cho HaNoiShop và SaiGonShop quản lý