1 / 103

Design Patterns

Design Patterns. Satya Puvvada. Objectives. Gain an understanding of using design patterns to improve design and implementation Learn to develop robust, efficient and reusable C++ programs using design patterns. Contents – Day 1. Introduction to design patterns Introduction to UML notation

nelsontina
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 Satya Puvvada Satya Puvvada

  2. Objectives • Gain an understanding of using design patterns to improve design and implementation • Learn to develop robust, efficient and reusable C++ programs using design patterns Satya Puvvada

  3. Contents – Day 1 • Introduction to design patterns • Introduction to UML notation • Patterns • Singleton • Factory method • Abstract Factory • Observer • Strategy • Adapter • Visitor Satya Puvvada

  4. Contents – Day 2 • Patterns • Builder • Bridge • Facade • Proxy • Composite • Chain of responsibility • Command Satya Puvvada

  5. Contents – Day 3 • Patterns • Flyweight • Memento • State • Decorator • Prototype • Mediator • Case Study • References and conclusions Satya Puvvada

  6. Why design patterns • Developing software is hard • Designing reusable software is more challenging – finding good objects and abstractions – flexibility, modularity, elegance reuse – takes time for them to emerge, trial and error • Successful designs do exist – exhibit recurring class and object structures Satya Puvvada

  7. Why OO Design Patterns • Effective for teaching OOD • OOP is a new Art form • People have only had ~20 years experience with OOP • Architecture and painting have been around for thousands of years. • Effective method of transferring skill and experience • new OO programmers can be overwhelmed by the options Satya Puvvada

  8. History of Design Patterns • Christopher Alexander - an architect • “The Timeless Way of Building”, 1979 • “A Pattern Language”, 1977 • Pattern - “ A solution to a problem in a context” • Purposes • effective reuse • dissemination of solutions Satya Puvvada

  9. History in OOP • 1987 workshop at OOPSLA Beck and Ward • 1993 The Hillside Group - Beck, Ward, Coplien, Booch, Kerth, Johnson • 1994 Pattern Languages of Programming (PLoP) Conference • 1995 Design Patterns : Elements of Reusable OO software - Gamma, Helm, Johnson, Vlissides (Gang of Four) Satya Puvvada

  10. Definitions / Terminology • Pattern Language - a term from Christopher Alexander, not a software language but a group of patterns used to construct a whole • Pattern - many definitions see FAQ, lets try this one: “Patterns represent distilled experience which, through their assimilation, convey expert insight and knowledge to inexpert developers. “ - Brad Appleton Satya Puvvada

  11. What is a design pattern • a standard solution to a common programming problem • a technique for making code more flexible by making it meet certain criteria • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • shorthand for describing certain aspects of program organization • connections among program components • the shape of a heap snapshot or object model Satya Puvvada

  12. What is a design pattern • Describes recurring design structure – names, abstracts from concrete designs – identifies classes, collaborations, responsibilities • applicability, trade-offs, consequences Satya Puvvada

  13. What is a design pattern • Design patterns represent solutions to problems that arise when developing software within a particular context • “Patterns == problem/solution pairs in a context” • Patterns capture the static and dynamic structure and collaboration among key participants in software designs • Especially good for describing how and why to resolve nonfunctional issues • Patterns facilitate reuse of successful software architectures and designs. Satya Puvvada

  14. Applications • Wide variety of application domains: drawing editors, banking, CAD, CAE, cellular network management, telecomm switches, program visualization • Wide variety of technical areas: user interface, communications, persistent objects, O/S kernels, distributed systems Satya Puvvada

  15. Definition • “Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice” Christopher Alexander, A Pattern Language, 1977 Satya Puvvada

  16. Design Patterns • A pattern has 4 essential elements: • Pattern name • Problem • Solution • Consequences Satya Puvvada

  17. Name - good name Intent- what does it do Also Known As Motivation - a scenario Applicability - when to use Structure- UML Participants - classes Collaborations - how they work together Consequences - trade offs Implementation- hints on implementation Sample Code Known Uses Related Patterns How a Pattern is Defined(GoF form) Satya Puvvada

  18. Classes of Design Patterns • Creational patterns: • Deal with initializing and configuring classes and objects • Structural patterns: • Deal with decoupling interface and implementation of classes and objects • Composition of classes or objects • Behavioral patterns: • Deal with dynamic interactions among societies of classes and objects • How they distribute responsibility Satya Puvvada

  19. UML Notation Satya Puvvada

  20. Class symbol 1.Name compartment 2. Attribute compartment 3. Operation compartment 4. Class name 5. Properties 6. Stereotype Satya Puvvada

  21. Class diagram - associations • Used to associate classes • Symbol used is a line with some adornments • Each association is given a name that matches the association Satya Puvvada

  22. Class diagram - multiplicity • A number of objects of each class may be associated • Customer may open many accounts, order may contain many items Asterisk (*) when used alone means zero or more, no lower or upper limit Asterisk (*) when used in a range (1..*) means no upper limit Values separated by two periods (..) means a range. Values separated by commas means an enumerated list of values. Satya Puvvada

  23. Class diagram - multiplicity Satya Puvvada

  24. Class diagram – Roles and constraints When an association cannot be give a name a role can be assigned to either ends of the association Satya Puvvada

  25. Class diagram – Roles and constraints 1.Role: Must have a name or roles or both 2. Association name: Must have a name or roles or both 3. Role: Must have a name or roles or both 4. Class 5. Constraint: Optional 6. Multiplicity: Required 7. Association 8. Multiplicity:Required 9. Class Satya Puvvada

  26. Class diagram – Reflexive associations 1.Objects in the same class is associated Satya Puvvada

  27. Class diagram – Qualified associations • Used to reduce multiplicity • Used like a database index • Can be used when both sides of an association has 0..* Satya Puvvada

  28. Class diagram – Association classes 1.A class that is used to give information about an association Satya Puvvada

  29. Class diagram – Aggregation and composition • Special type of association • Used to show that a class is made up of other classes Satya Puvvada

  30. Class diagram – composition • Similar to aggregation • It is used when the lifespan of the parts depend on the lifespan of the aggregate Satya Puvvada

  31. Class diagram – generalization Same as inheritance No multiplicity shown Links classes together where each class consists a subset of the element that is to be finally defined Satya Puvvada

  32. Class diagram – delegation Can be used to reduce generalization Makes one class a part of another class using aggregation Satya Puvvada

  33. Sequence diagrams 1. Object lifeline 2. Message/Stimulus 3. Iteration 4. Self-reference 5. Return 6. Anonymous object 7. Object name 8. Sequence number 9. Condition 10. Basic comment Satya Puvvada

  34. Sequence diagrams 1. Activation: The start of the vertical rectangle, the activation bar 2. Deactivation: The end of the vertical rectangle, the activation bar 3. Timeout event: Typically signified by a full arrowhead with a small clock face or circle on the line 4. Asynchronous event: Typically signified by stick arrowhead 5. Object termination symbolized by an X 6. Synchronous message: Typically signified with a solid line and filled arrowhead 7. Return: Typically signified with a dashed line and line stick arrowhead Satya Puvvada

  35. Collaboration diagrams – Satya Puvvada

  36. Collaboration diagram - observer Satya Puvvada

  37. Patterns Satya Puvvada

  38. Singleton Pattern - Creational • The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. • Examples: • There can be many printers in a system but there should only be one printer spooler. • There should be only one instance of a WindowManager (GrainWindowingSystem). • There should be only one instance of a filesystem. Satya Puvvada

  39. Singleton Pattern • How do we ensure that a class has only one instance and that the instance is easily accessible? • A global variable makes an object accessible, but does not keep you from instantiating multiple objects. • A better solution is to make the class itself responsible for keeping track of its sole instance. The class ensures that no other instance can be created (by intercepting requests to create new objects) and it provides a way to access the instance. Satya Puvvada

  40. Singleton Pattern Use the Singleton pattern when • There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point. • When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code. Satya Puvvada

  41. Singleton Structure • Singleton • static Instance() • SingletonOperation() • GetSingletonData() • static uniqueinstance • singletonData return uniqueinstance Satya Puvvada

  42. Singleton Particpants • Singleton • Defines an Instance operation that lets clients access its unique instance. Instance is a class operation (static member function in C++) • May be responsible for creating its own unique instance • Client • Acesses a Singleton instance solely through Singleton’s Instance operation. Satya Puvvada

  43. Singleton Consequences • Controlled access to sole instance Because the Singleton class encapsulates its sole instance, it can have strict control over how and when clients access it. • Reduced name space The Singleton pattern is an improvement over global variables. It avoids polluting the name space with global variables that store sole instances. Satya Puvvada

  44. Singleton Consequences • Permits refinement of operations and representations The Singleton class may be subclassed and it is easy to configure an application with an instance of this extended class at run-time. Satya Puvvada

  45. Singleton Implementation • Ensuring a unique instance The Singleton pattern makes the sole instance a normal instance of a class, but that class is written so that only one instance can ever be created. A common way to do this is to hide the operation that creates the instance behind a static class operation that guarantees that only one instance is created. Satya Puvvada

  46. Singleton Sample Code class Singleton { public: static Singleton* Instance(); // clients access the Singleton exclusively through // the Instance() member function protected: Singleton() {} // the constructor is protected, such that a client // which tries to instantiate a Singleton object gets // a compiler error private: static Singleton* instance_; }; Satya Puvvada

  47. Singleton Sample Code Singleton* Singleton::instance_ = 0; // initialize static member data of class Singleton Singleton* Singleton::Instance() { if (instance_ == 0) // if not created yet instance_ = new Singleton; // create once return instance_; } Satya Puvvada

  48. Synopsis: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses • Context: Example is that of a GUI framework. The generic Application class will have a method createDocument to create a generic document. A specific use of the framework for, say, word-processing GUI would subclass the generic Application class and override the createDocument method to generate word-processing documents. Pattern Factory Method Satya Puvvada

  49. • Forces: Use the Factory Method pattern when: – a class can’t anticipate the class of objects it must create – a class wants its subclasses to specify the objects it creates – the set of classes to be generated may be dynamic Pattern Factory Method Satya Puvvada

  50. Solution: Use a factory method to create the instances: – Product (e.g. Document) – defines the interface of objects the factory method creates – ConcreteProduct (e.g. MyDocument) – implements the Product interface – Creator (e.g. Application) – declares the factory method which returns an object of type Product (possibly with a default implementation); may call the factory method to create a Produce object – ConcreteCreator (e.g. MyApplication) – overrides the factory method to return an instance of ConcreteProduct Pattern Factory Method Satya Puvvada

More Related