1 / 30

Design Patterns

Design Patterns. What is wrong with this picture?. Ball. Enemy. Private:. Private:. double gravity 32.1. double gravity 32.1. Don’t repeat yourself!. How about this?. Global double gravity 3.21. We’re not using a constant because we want to support different worlds with

cameo
Télécharger la présentation

Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Patterns

  2. What is wrong with this picture? Ball Enemy Private: Private: double gravity 32.1 double gravity 32.1 Don’t repeat yourself!

  3. How about this? Global double gravity 3.21 We’re not using a constant because we want to support different worlds with different gravitational forces.

  4. Why not use globals? • They make code hard to debug. • They make code hard to change. • Profs O’Neill and Kuenning will haunt your dreams if you do. Answer: All of the above This is a Design Pattern....

  5. Design Patterns • Description of the problem. • Essence of a solution • Description of accumulated knowledge. • Book: Design Patterns, by gang of 4. • Web page devoted to software Design Patterns: http://hillside.net

  6. Elements of a Design Pattern • Name that is meaningful • Description of the problem area that explains when the pattern may be applied • A solution description of the parts of the design solution, their relationships, and their responsibilities. • not a concrete design description, but a template • many times expressed graphically - UML • Statement of the consequences of applying the pattern • results and trade-offs • used to indicate applicability

  7. The Observer pattern

  8. Observer Pattern: Multiple displays

  9. UML model of the Observer pattern

  10. Using Design Patterns • Is a design process • develop a design • experiencing a problem • recognizing that an existing pattern can be used • most difficult step is the need for a taxonomy of Design Patterns

  11. Singleton Pattern Problem: Ensure a class has only one instance and provide a global point of access to that instance.

  12. Singleton Gravity Class class Gravity { public: static Gravity* getInstance(); double getGravity(); private: static Gravity* theGravityInstance; Gravity() {}; ~Gravity) {}; Gravity(const Gravity& toCopy) {}; Gravity& operator=(const Gravity& toCopy) {}; }; Gravity::Gravity* theGravityInstance = NULL; users can ask for a pointer to THE instance and then get the value for gravity the constructor is private

  13. Problem: You need to use a subset of a complex system or you need to interact with the system in a particular way. façade Design Pattern

  14. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can make a software lib easier to use, understand and test. A facade can make code more readable because it has convenient methods for common tasks A facade can reduce dependencies of outside code on library inner workings. A facade is a wrapper façade

  15. Triangle2D Triangle3D tuple3D vertices[3] triangle() triangle(tuple3D v[3] ~triangle() set color(r, g, b) rotate(vector, angle) translate(dx, dy, dz) scale(sx, sy, sz) draw() set z=0 2d rotate about origin, use 3d rotate about <0,0,1> etc. Triangle 2D is special case of Triangle 3D

  16. facade: Triangle2D Triangle3D tuple3D vertices[3] triangle() triangle(tuple3D v[3]) ~triangle() set color(r, g, b) rotate(vector, angle) translate(dx, dy, dz) scale(sx, sy, sz) draw() • Triangle2D • Triangle3D* myTriangle • triangle() • triangle(tuple2D v[3]) • ~triangle() • set color(r, g, b) • rotate(angle) • translate(dx, dy) • scale(sx, sy) • draw() MORE INTUITIVE, Hides the 3D interface.

  17. Strategy design pattern Problem: Want to be able to swap the algorithm used in an application at runtime Solution: Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable Strategy DP lets the algorithm vary independently from the clients that use it.

  18. I want to support two (or more) different collision detection algorithms. cPhysicsEngine Encapsulate change cPhysicsFast cPhysicsSlow In the future I may want to use a super slow algorithm.

  19. UML of Strategy DP

  20. Strategy Design Pattern cPhysicsEngine cDetectCollision • supports several design principles: • encapsulate change • open-closed principle • single responsibility principles • favor composition over inheritance cDetectCollisionFast cDetectCollisionSlow

  21. Bridge Pattern Problem: Want to decouple implementation from abstraction so they can change independently A teacher (Communicator object) can talk to any kid (talkable object), and a kid should also allow any teacher (Communicator object) to start talking to him/her as well. Just like how printers work with computers. If we have a USB cable (bridge), then we can connect any printer to any computer to start printing. It really doesn't matter if it's a laser printer or a color printer, either Windows PC or Mac. Because we know all the printers will allow the computers to print, makes sense?

  22. OpenGL DirectX Bridge Shape draw() Graphics package abstracts interface Decouple abstraction from implementation Circle draw() Rectangle draw() OpenGL adapter DirectX adapter wrappers

  23. State Design Pattern Problem: want to allow an object to alter its behavior when its internal state changes

  24. State Design Pattern PaintProgram processKey processMouse Mode processKey processMouse 1 Spray Paint Eraser Fill supports open-closed, encapsulate change, single responsibility principles

  25. State Design Pattern Mode mgr. returns pointer to correct mode, i.e., Key or Mouse handling function PaintProgram processKey processMouse Mode processKey processMouse 1 1 ModeManager processKey processMouse Spray Paint Eraser Fill 1 1 1

  26. Command Design Pattern Encapsulate a request as an object to permit logging, queuing, un-doing etc. an object is used to represent and encapsulate all the info needed to call a method at a later time. Includes method name, object that owns that method and values for any parms,.

  27. Command Design Pattern Command Key Mouse Menu

  28. MVC Design PatternModel-view-Controller • The pattern isolates “domain logic” (application logic for the user) from the user interface permitting independent development, testing and maintenance of each (separation of concerns) • user interacts with user interface, e.g., button • controller converts into understandable action for the model • controller tells model of user action (model state may change) • view queries model to generate user interface; view gets its date from model. • view may render itself or is notified by model of changes in state that require screen update

  29. MVC supports high cohesion and low coupling

  30. Other design patterns wikipedia http://hillside.net books

More Related