Design pattern
•Download as PPTX, PDF•
2 likes•315 views
This document discusses various design patterns that could be used to model player management in a game including creating player info, attributes, factories, builders, prototypes, singletons, adapters, bridges, composites, decorators, facades, flyweights, proxies, chain of responsibility, commands, iterators, mediators, mementos, observers, states, strategies, templates, and visitors. It provides examples of how each pattern could be applied to common issues that may arise such as generating players, handling different data formats, combining properties, relationships between parts and wholes, adding new properties over time, performing calculations, tracking history, updating values, and modeling state changes.
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to Design pattern
Similar to Design pattern (20)
Recently uploaded
Recently uploaded (20)
Design pattern
- 4. Attributes
- 5. Big Trouble! How can I generate a player with many properties? Class inheritance ? Class flood! Client requirment: creation process independent
- 7. Abstract Factory Scene Implementation Features
- 8. Attack property indication Shoot Pass Head Assist ……
- 9. Factory
- 10. Factory Scene Implementation Features
- 11. Calculate different values Shoot algorithm Assist algorithm Pass algorithm ……
- 12. Builder
- 13. Builder Scene Implementation Features
- 14. Almost similar A new player is almost the same with an existing player, shall I create him/her with factory or other better method?
- 15. Prototype
- 16. Prototype Scene Implementation Features
- 17. One club one national Use a club or a national repeatedly
- 18. Singleton
- 19. Singleton Scene Implementation Features
- 20. Information mismatch Factory accepts a uncommon info form a table, a list or other form? How to adapt it into standard style?
- 21. Adapter
- 24. Combine properties How to combine so many properties into a player?
- 25. Bridge Scene Implementation Features
- 26. A team and a player Relationship between Integrity and part But they should be represented with the same class!
- 27. Composite
- 28. Composite Scene Implementation Features
- 29. New property in future Modify composite? Add new factory class?
- 30. Decorator
- 31. Decorator Scene Implementation Features
- 32. Complex internal handle Find a player with some condition, from where?
- 33. Facade
- 34. Facade Scene Implementation Features
- 35. Fewer nationals For number, nationals are fewer than clubs, but creating a new national cost so much, so how to handle it?
- 36. Flyweight
- 37. Flyweight Scene Implementation Features
- 38. Dangerous player Wild player to display as inconsistent, so we need a filter to handle their performance
- 39. Proxy
- 40. Proxy Scene Implementation Features
- 41. Uncertain situation For a strange data, I can’t confirm who will handle it, how to do that?
- 43. Chain of responsibility Scene Implementation Features
- 44. Decouple How can I decouple request and handle, other than invoke directly?
- 45. Command
- 46. Command Scene Implementation Features
- 47. Grammar A language model, which is relative with language Interpret model
- 48. Process sequentially I want to process players which are not only in clubs, but also in nationals, sequentially, but they are different in appearance
- 49. Iterator
- 50. Iterator Scene Implementation Features
- 51. Communication Communicate between different departments, it is a multi-multi relationship, so every class has functions which are used for communication with other classes, so complex! What shall we do?
- 52. Mediator
- 53. Mediator Scene Implementation Features
- 54. History log I want to look up a player’s history performance to determine whether to hire him. How can I check former records?
- 55. Memento
- 56. Memento Scene Implementation Features
- 57. Event mechanism I want to update players’ experience value after a game, how can I notify them?
- 58. Observer
- 59. Observer Scene Implementation Features
- 60. Player’s sick Once a player caught a serious cold, how can I change his/her state?
- 61. State
- 62. State Scene Implementation Features
- 63. Different algorithm Beckham and Ronaldo have different algorithms for their shoot value My god, for so many players how can I process the calculation?
- 64. Strategy
- 65. Strategy Scene Implementation Features
- 66. Detail difference Some property just has trivial difference in calculation, how can I handle this? Use strategy?
- 67. Template
- 68. Template Scene Implementation Features
- 69. Just data change! The last scene, just data change, but calculation way will not change frequently
- 70. Visitor
- 71. Visitor Scene Implementation Features
Editor's Notes
- Create/structure/activity
- Abstract FactoryScene: an object with multiple properties, and it will be created by a factory objectImplementation: abstract factory class define create different objects’ functions, which will return a property’s different objects, then inheritance class will implement other properties.Features: separate new class process with factory class and with multiple properties.
- Factory modelScene: forbid class new process, encapsulate class creation process, create class according to class nameImplementation: just a simple “Create” function which is inside of Factory class, inside it you can use string or if logic to control it.Features: decouple user use and create process
- BuilderScene: different objects with different creation processImplementation: base class supplies multiple sub-process, child class use them with different sequence to create an objectFeatures: encapsulate different build internal process
- PrototypeScene: some instances have similar propertiesImplementation: inside class supply a clone function which will call copy constructor functionFeatures: constructor function is complex and instances are almost the same is some properties
- SingletonScene: one resource will be used repeatedlyImplementation: whenever requesting an object, test whether it has been createdFeatures: every time just one object is existing
- BridgeImplementation: every property is added into main class as a data member
- CompositeScene: seem integrity and part as the sameImplementation: composite class contain a leaf objectFeatures: recursive handle
- DecoratorScene: new properties in the future which can’t be foresawImplementation: decorator sub-classes contain a decorated object, and handle itFeatures: just add a new sub-class in the future
- FaçadeScene: complex internal handle, no way to enter!Implementation: supply an interface to accept handle requestFeatures: compare with chain of responsibility model
- FlyweightScene: construction class is so complex to create an objectImplementation: maintain a pool to store various of instances, if a new instance is not be created, then create it and push it into the poolFeatures: compare with singleton model
- ProxyScene: accept request to replace or ease real processor’s pressureImplementation: create a proxy class to call real class by adding some new filtersFeatures: proxy server
- Chain of responsibilityScene:Implementation: inside of main class, there exists a successor object to reallocate task to sub-class to handle.Features: compare with façade model
- CommandScene: decouple request and process classImplementation: add a middle class as Command to encapsulate real process class and be invoked be invoker, clients will invoke invoker.Features: second encapsulation
- IteratorScene:stl container, supply an interface to visit different objects sequentiallyImplementation: for various of containers, implement the iterator interface to complete “next” functionFeatures: somehow like as adapter
- MediatorScene: for handling complex and many relationship between different classesImplementation: create a new class for handle every two classed independentlyFeatures: from dispatch to concentrate
- MementoScene: I need to fall back to check some status.Implementation: create memento/store/generator classed to present, store and generator memento respectively, and inside of generator and store classes there exists an internal memento object.Features: retreating model
- ObserverScene: event call back sceneImplementation: a notification machine will supply attach and detach functions to register and delete observers, and observers implement execute method, once something happens, then the notification class will invoke all observers’ execute functionsFeatures: event asynchronous handle mechanism
- StateScene: state machine, multiple states and transitionsImplementation: every state will be implemented as a class, then transitions will be encapsulated inside a state classFeatures: compare with strategy model
- StrategyScene: for market example, different goods have different discount information Implementation: different situation has its own algorithm, and these algorithms implement the same interface Features: compare with state
- TemplateScene:c++ template algorithm for different data typeImplementation: façade is the same, but inside the function, some sub-function will be implemented differentlyFeatures: compare with state and strategy models
- VisitorScene: data as accepter, algorithm as visitorImplementation: data will be main class to invoke algorithm class object, algorithm class has a function execute which will accept an accepter parameterFeatures: complex design pattern