Download to read offline
![[DevDay 2016] Design Pattern at a glance - Speaker: Tuan Do – Scrum Master a...](https://cdn.slidesharecdn.com/ss_thumbnails/designpattern-devday2016-160414034636-thumbnail.jpg?width=640&height=640&fit=bounds)
SOLID & Design patterns.pptx
- 1.
- 2. Agenda ● Intro ● SOLID ●Design patterns ○ Decorator ○ Strategy ○ Visitor ● Q & A
- 3. Intro - Design patternskhông khó hiểu nếu chúng ta nắm vững SOLID. - Design patterns trở nên quen thuộc, gần gũi. - Design patterns trở thành công cụ giao tiếp.
- 5.
- 6. SOLID > BadDesign
- 7. SOLID > GoodDesign Maintainability
- 8. SOLID > SingleResponsibility Support Maintainability Reusability Testability Eliminate Rigidity Fragility Immobility
- 9. SOLID > SingleResponsibility
- 10.
- 11.
- 12. SOLID > Liskovsubstitution Support Reusability Extensibility Maintainability Eliminate Fragility Immobility Opacity
- 13. SOLID > Liskovsubstitution
- 14. SOLID > InterfaceSegregation Support Maintainability Reusability Testability Eliminate Rigidity Opacity Immobility
- 15. SOLID > InterfaceSegregation
- 16. SOLID > DependencyInversion Support Extensibility Maintainability Testability Eliminate Immobility Viscosity Rigidity
- 17. SOLID > DependencyInversion
- 18. SOLID > DependencyInversion
- 19. SOLID > DependencyInversion
- 20. SOLID > DependencyInversion
- 21. SOLID > DependencyInversion
- 22. Advices ● A classshould have only one reason to change. ● Favor Composition over inheritance ● Program to interfaces, not implementations. ● DRY Principle: Don't Repeat Yourself
- 23. Design Pattern Design patternsare typical solutions to common problems in software design
- 24.
- 25. Design Pattern >Diagram
- 26.
- 27. Decorator Pattern Attach additionalresponsibility dynamically during runtime. Trong đầm gì đẹp bằng sen Lá xanh bông trắng lại chen nhụy vàng
- 28.
- 29. Decorator Pattern >Example
- 30. Decorator Pattern >Example
- 31. Decorator Pattern >Example
- 32. Decorator Pattern >Example
- 33. Decorator Pattern >Example
- 34. Decorator Pattern >Real Example
- 35. Bánh + nước DecoratorPattern > Real Example Cước Wifi Dịch vụ Dịch_vụ_tùy_chọn
- 36.
- 37. Strategy Pattern Define afamily of algorithms, encapsulate each one, and make them interchangeable. Con gà cục tác: “lá chanh” Con lợn ủn ỉn “Mua hành cho tôi” Con chó khóc đứng khóc ngồi: “Bà ơi đi chợ mua tôi đồng riềng”.
- 38. Strategy Pattern >Diagram Món chính (gà, heo, chó) Lá chanh Củ hành Củ riềng
- 39.
- 40. Strategy Pattern >Example
- 41. Strategy Pattern >Example
- 42. Strategy Pattern >Example
- 43. Strategy Pattern >Real Example
- 44. Strategy Pattern >Real Example Đơn Hàng Tín dụng Momo Bitcoin
- 45.
- 46. Visitor Pattern A wayof separating an algorithm from an object structure on which it operates.Visitor lets you add new operations to existent object structures without modifying the structures. Dẫn lang nhập thất
- 47. Visitor Pattern Phòng kháchNhà bếp Sói
- 48. Visitor Pattern >Example
- 49. Visitor Pattern >Example
- 50. Visitor Pattern >Example
- 51. Visitor Pattern >Example
- 52. Visitor Pattern >Real Example
- 53. Visitor Pattern >Real Example Mô tả SP Bình luận Đánh giá SP
- 54. Recap ● SOLID ● Designpatterns ○ Decorator ○ Strategy ○ Visitor ● Design patterns & ca dao tục ngữ ● Caution ○ Use the right tool for the job Example on Github https://github.com/khoiquyenvn/designpattern
- 55.
- 56. Thanks! Contact us: KMS Technology 2Tản Viên, P.2, Q.Tân Bình khoimnguyen@kms-technology.com www.kms-technology.com
Editor's Notes
- #4 Công cụ để biểu đạt (nói rất ngắn gọn, nhưng khả năng diễn đạt cao) Lý do gây trở ngại cho việc hiểu DP là do ko hiểu SOLID Design pattern trở thành thân thuộc, gần gũi Xa hơn, hi vọng mọi người có thể sử dụng DP như công cụ giao tiếp công việc với nhau hằng ngày 3 patterns chuyên dùng để đối phó với vấn đề change requirement + mở rộng tính năng
- #6 Là 1 phương pháp lập trình Chia chương trình thành các đối tượng và các đối tượng này tương tác với nhau
- #7 Che dấu sự phức tạp
- #8 Che dấu để bảo vệ tính đúng đắn của dữ liệu (internal state)
- #9 Reuse 100% đối tượng đã có sẵn
- #11 Ở thời điểm thực thi, mới xác định sẽ là đối tượng nào từ đó mới xác định cách thức
- #12 Viết tắt của 5 nguyên lý trong thiết kế phần mềm theo hướng OOP Bộ nguyên tắc thiết kế Giống như kim chỉ nam Như nguyên tắc tham gia giao thông, có hàng trăm biển báo nhưng chỉ có 4 nguyên tắc. Nguyên tắc thì rất ngắn gọn Nếu tuân thủ đúng sẽ tạo ra đc tính dễ hiểu, dễ đọc > dễ bảo trì, sửa chữa, mở rộng
- #14 Maintainability: dễ đọc, dễ hiểu, tính gắn kết, nhất quán. Thường đc đo bằng khoảng thời gian mà bạn nghĩ để thay đổi một thứ gì đó so với thực tế. Reusability: có thể tái sử dụng đc một vài component của project cũ thay vì phải đem toàn bộ component qua proj mới. Ví dụ: payment Extensibility: khả năng mở rộng, phát triển thêm tính năng mới, mà với chi phí thay đổi là thấp nhất có thể Testability: Unit test Efficiency: sử dụng tài nguyên hiệu quả, tổng ko đổi
- #15 Hành vi Consistent xuyên suốt trong program Xác định rõ ràng nhiệm vụ của mỗi class => khi cần thay đổi thì số chỗ cần phải thay đổi là ít nhất lead to god class, domino theory if a change to the App1 causes the common class, that change may force us to rebuild, retest, and redeploy the App2. If we forget to do this, that application may break in unpredictable ways.
- #16 Single responsibility in a bounded context. Ex : a car engine
- #17 Support cho tính extensibility, bằng cách thêm mới thành phần thay vì thay đổi cái cũ. An toàn hơn & tiết kiệm hơn Chương trình viết ra là để thay đổi > nên thay vì debate chúng ta sẽ tìm cách làm cho việc thay đổi dễ dàng hơn cách duy nhất để thêm tính năng mới là modify class cũ > mất tính đúng đắn của class cũ > test lại designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change. 3 patterns đc giới thiệu hôm nay sẽ liên quan đến nguyên lý này Abstraction is key
- #18 Chương trình viết ra là để thay đổi > nên thay vì debate chúng ta sẽ tìm cách làm cho việc thay đổi dễ dàng hơn Abstraction is key Ex: thiết bị lọc nước Why: cách duy nhất để thêm tính năng mới là modify class cũ > mất tính đúng đắn của class cũ > test lại Reusability & Maintainability designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change. 3 patterns đc giới thiệu hôm nay sẽ liên quan đến nguyên lý này
- #19 Là nguyên lý đảm bảo cho tính kế thừa đúng Logic trong thế giới lập trình và logic trong thực tế đôi khi không đồng nhất với nhau. Ex: chim cánh cụt why : It may lead to violate o/c principle (add new subclass > have to modify base class) Cause unpredictable error
- #20 Logic trong thế giới lập trình và logic trong thực tế đôi khi không đồng nhất với nhau. Ex: chim cánh cụt why : It may lead to violate o/c principle (add new subclass > have to modify base class) Cause unpredictable error
- #21 Kế thừa class vs implement interface Tách nhỏ interface sao cho đủ chức năng, ko quá lớn > tạo thành gánh nặng, ko quá nhỏ > phân mảnh Không buộc client phải implement những gì mà họ ko sử dụng SR vs IS Ex: Bánh trung thu
- #22 Tách nhỏ interface sao cho đủ chức năng, ko quá lớn > tạo thành gánh nặng, ko quá nhỏ > phân mảnh Không buộc client phải implement những gì mà họ ko sử dụng SR from designer view vs IS client view Ex: Bánh trung thu
- #23 là cái khung chương trình, mình có thể lập trình trước, sau đó mới lắp các thành phần cụ thể vào High level module should not depend on low level module, both should depend on abstraction. Abstraction should not depend on detail, detail should depend on abstraction. Định nghĩa cách thức giao tiếp trước
- #24 High level module should not depend on low level module, both should depend on abstraction. Abstraction should not depend on detail, detail should depend on abstraction. Định nghĩa cách thức giao tiếp trước
- #25 High level module should not depend on low level module, both should depend on abstraction. Abstraction should not depend on detail, detail should depend on abstraction. Định nghĩa cách thức giao tiếp trước
- #26 High level module should not depend on low level module, both should depend on abstraction. Abstraction should not depend on detail, detail should depend on abstraction. Định nghĩa cách thức giao tiếp trước
- #27 High level module should not depend on low level module, both should depend on abstraction. Abstraction should not depend on detail, detail should depend on abstraction. Định nghĩa cách thức giao tiếp trước
- #28 DIP means that you program against an abstraction. IOC means that somebody else is responsible for getting the implementation for the given abstraction (eliminate new keyword) You can use an IoC Container as a Service Locator > you couple them all to the Service Locator IoC Container you use Dependency Injection > auto-wiring
- #33 3 patterns comply with open/close principle.
- #34 Sử dụng đúng công cụ vào đúng hoàn cảnh, tránh việc nhồi nhét pattern vào project > gánh nặng ko cần thiết.
- #37 3 phương tiện truyền tải: Câu ca dao tục ngữ, đi kèm hình ảnh, class Diagram của pattern. kèm chú thích tương ứng với câu ca dao Câu chuyện công ty xà bần, yêu cầu từ khách hàng, class diagram và chú thích tương ứng Code demo còn bông nào khác mà khen bây giờ? :D
- #48 Nồi đồng nấu ốc, nồi đất nấu ếch Ăn cơm Tàu, ở nhà Tây, lấy vợ Nhật Đi với bụt mặc áo cà sa, đi với ma mặc áo giấy
- #58 Dẫn sói vào nhà Cõng rắn cắn gà nhà Rước voi về giày mã tổ Áp dụng cho các cấu trúc dữ liệu phức tạp, pattern dùng để tách hành động ra khỏi cấu trúc đối tượng và xem nó như khách, Nhiệm vụ của cấu trúc dữ liệu chỉ là “dẫn” khách đi qua các thành phần trong cấu trúc của mình