1. 91.204.201 Computing IV Introduction to Design Pattern Xinwen Fu

2. CS@UML By Dr. Xinwen Fu2 Outline  Introduction to Pattern  Gang of Four Design Pattern  Adapter Pattern  Introduction to UML

3. CS@UML By Dr. Xinwen Fu3 What is a Pattern?  Current use comes from the work of the architect Christopher Alexander  Alexander studied ways to improve the process of designing buildings and urban areas  “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem and a solution.”  Hence, the common definition of a pattern: “A solution to a problem in a context.”  Patterns can be applied to many different areas of human endeavor, including software development

4. CS@UML Pattern of Porches By Dr. Xinwen Fu4 American Colonial Styles Classical House Styles Victorian House Styles Spanish and Mediterranean

5. CS@UML By Dr. Xinwen Fu5 Why Patterns?  "Designing object-oriented software is hard and designing reusable object-oriented software is even harder." - Erich Gamma  Experienced designers reuse solutions that have worked in the past  Well-structured object-oriented systems have recurring patterns of classes and objects  Knowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable

6. CS@UML By Dr. Xinwen Fu6 Software Patterns History  1987 - Cunningham and Beck used Alexander’s ideas to develop a small pattern language for Smalltalk  1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns  1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA  1993 - Kent Beck and Grady Booch sponsor the first meeting of what is now known as the Hillside Group  1994 - First Pattern Languages of Programs (PLoP) conference  1995 - The Gang of Four (GoF) publish the Design Patterns book

7. CS@UML By Dr. Xinwen Fu7 Types of Software Patterns  Riehle and Zullighoven in “Understanding and Using Patterns in Software Development” mention three types of software patterns  Conceptual Pattern Pattern whose form is described by means of terms and concepts from the application domain  Design Pattern Pattern whose form is described by means of software design constructs, such as objects, classes, inheritance and aggregation  Programming Pattern (Programming Idiom) Pattern whose form is described by means of programming language constructs

8. CS@UML By Dr. Xinwen Fu8 Design Pattern: Levels of Abstraction  Complex design for an entire application or subsystem - Conceptual Pattern  Solution to a general design problem in a particular context - Design Pattern  Simple reusable design class such as a linked list, hash table, etc. - Programming Pattern

9. CS@UML By Dr. Xinwen Fu9 Outline  Introduction to Pattern  Gang of Four Design Pattern  Adapter Pattern  Introduction to UML

10. CS@UML By Dr. Xinwen Fu10 GoF Design Patterns  The GoF design patterns are in the middle of these levels of abstraction  “A design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design.”  The GoF design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”

11. CS@UML By Dr. Xinwen Fu11 GoF Classification Of Design Patterns  Purpose - what a pattern does  Creational Patterns Concern the process of object creation  Structural Patterns Deal with the composition of classes and objects  Behavioral Patterns Deal with the interaction of classes and objects

12. CS@UML PurposeDesign PatternAspect(s) That Can Vary CreationalAbstract Factory (99)families of product objects Builder (110)how a composite object gets created Factory Method (121)subclass of object that is instantiated Prototype (133)class of object that is instantiated Singleton (144)the sole instance of a class StructuralAdapter (157)interface to an object Bridge (171)implementation of an object Composite (183)structure and composition of an object Decorator (196)responsibilities of an object without subclassing Facade (208)interface to a subsystem Flyweight (218)storage costs of objects Proxy (233)how an object is accessed; its location BehavioralChain of Responsibility (251) object that can fulfill a request Command (263)when and how a request is fulfilled Interpreter (274)grammar and interpretation of a language Iterator (289)how an aggregate's elements are accessed, traversed Mediator (305)how and which objects interact with each other Memento (316)what private information is stored outside an object, and when Observer (326)number of objects that depend on another object; how the dependent objects stay up to date State (338)states of an object Strategy (349)an algorithm Template Method (360)steps of an algorithm Visitor (366)operations that can be applied to object(s) without changing their class(es)

13. CS@UML Online Materials  Design Patterns Design Patterns  Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software, Addison Wesley. October 1994. By Dr. Xinwen Fu13

14. CS@UML Iterator By Dr. Xinwen Fu14

15. CS@UML By Dr. Xinwen Fu15 Outline  Introduction to Pattern  Gang of Four Design Pattern  Adapter Pattern  Introduction to UML

16. CS@UML By Dr. Xinwen Fu16 C++ Example 1. #include 2. using namespace std; 3. typedef int Coordinate; 4. typedef int Dimension; 5. // Desired interface 6. class Rectangle { 7. public: 8. virtual void draw() = 0; 9. }; 10. // Legacy component 11. class LegacyRectangle { 12. public: 13. LegacyRectangle(Coordinate x1, Coordinate y1, Coordinate x2, Coordinate y2) { 14. x1_ = x1; 15. y1_ = y1; 16. x2_ = x2; 17. y2_ = y2; 18. cout (" 19. << x2_ << "," << y2_ << ")" << endl; 20. }

17. CS@UML By Dr. Xinwen Fu17 1. void oldDraw() { 2. cout << "LegacyRectangle: oldDraw. (" << x1_ << "," << y1_ << 3. ") => (" << x2_ << "," << y2_ << ")" << endl; 4. } 5. private: 6. Coordinate x1_; 7. Coordinate y1_; 8. Coordinate x2_; 9. Coordinate y2_; 10. }; 11. // Adapter wrapper 12. class RectangleAdapter: public Rectangle, private LegacyRectangle { 13. public: 14. RectangleAdapter(Coordinate x, Coordinate y, Dimension w, Dimension h): 15. LegacyRectangle(x, y, x + w, y + h) { 16. cout << "RectangleAdapter: create. (" << x << "," << y << 17. "), width = " << w << ", height = " << h << endl; 18. } 19. virtual void draw() { 20. cout << "RectangleAdapter: draw." << endl; 21. oldDraw(); 22. } 23. }; 24. int main() { 25. Rectangle *r = new RectangleAdapter(120, 200, 60, 40); 26. r->draw(); 27. }

18. CS@UML Understanding the Start of an Object's Lifetime 1. #include 2. class Foo { 3. public: 4. Foo() { std::cout << "Foo's constructor" << std::endl; } 5. }; 6. class Bar : public Foo { 7. public: 8. Bar() { std::cout << "Bar's constructor" << std::endl; } 9. }; 10. int main() { 11. // a lovely elephant ;) 12. Bar bar; 13. } By Dr. Xinwen Fu18

19. CS@UML By Dr. Xinwen Fu19 The Adapter Pattern  Intent Convert the interface of a class into another interface clients expect Adapter lets classes work together that couldn't otherwise because of incompatible interfaces  Also Known As Wrapper  Motivation Sometimes a toolkit or class library cannot be used because its interface is incompatible with the interface required by an application We cannot change the library interface, since we may not have its source code Even if we did have the source code, we probably should not change the library for each domain-specific application

20. CS@UML By Dr. Xinwen Fu20 Outline  Introduction to Pattern  Gang of Four Design Pattern  Adapter Pattern  Introduction to UML

21. CS@UML By Dr. Xinwen Fu21 Use of Adapter pattern  Applicability: Use the Adapter pattern when You want to use an existing class, and its interface does not match the one you need You want to create a reusable class that cooperates with unrelated classes with incompatible interfaces  Implementation Issues How much adapting should be done?  Simple interface conversion that just changes operation names and order of arguments  Totally different set of operations Does the adapter provide two-way transparency?  A two-way adapter supports both the Target and the Adaptee interface. It allows an adapted object (Adapter) to appear as an Adaptee object or a Target object

22. CS@UML By Dr. Xinwen Fu22 Class Adapter  A class adapter uses multiple inheritance to adapt one interface to another

23. CS@UML By Dr. Xinwen Fu23 Object Adapter  An object adapter relies on object composition

24. CS@UML By Dr. Xinwen Fu24 Outline  Introduction to Pattern  Gang of Four Design Pattern  Adapter Pattern  Introduction to UML

25. CS@UML 25 Objectives of UML  UML is the result of an effort to simplify and consolidate the large number of OO development methods and notations  UML is a general purpose notation that is used to visualize, specify, construct, and document the artifacts of a software system

26. CS@UML 26 A Class in UML Class name Attribute Operator Mark Visibility type +Public #Protected -Private ~Package  Class name: Must have, other two are optional  Attribute format name : attribute type = default value  Operation (method) format Name(paramater list): return type

27. CS@UML 27 Object Diagram object name : class

28. CS@UML 28 Class Relationships in UML  Inheritance An inheritance link: triangle pointing to superclass  Association A relationship between instances of the two classes Two ends: an end can have a role name to clarify the nature of the association The number of possible instances of the class associated with a a single instance at the other end  Dependency One depends on another if changes in the other could possibly force changes in the first

29. CS@UML Visual Paradigm for UML 10.1 Community Edition  Visual Paradigm for UML is a UML modeling software that supports UML, SysML, ERD, BPMN, DFD, ArchiMate, etc. UML diagrams, use case, SysML requirements, enterprise architecture, code engineering and database design are supported for effective system analysis and design. Visual Paradigm for UML  Youtube videos on UML Youtube videos By Dr. Xinwen Fu29

30. CS@UML Backup By Dr. Xinwen Fu30

31. CS@UML By Dr. Xinwen Fu31

32. CS@UML By Dr. Xinwen Fu32 Two-Way Adapter Example in Java  Here are the interfaces for round and square pegs: 1. /** 2. *The IRoundPeg interface. 3. */ 4. public interface IRoundPeg { 5. public void insertIntoHole(String msg); 6. } 7. /** 8. *The ISquarePeg interface. 9. */ 10. public interface ISquarePeg { 11. public void insert(String str); 12. }

33. CS@UML By Dr. Xinwen Fu33 RoundPeg and SquarePeg Classes 1. // The RoundPeg class. 2. public class RoundPeg implements IRoundPeg { 3. void insertIntoHole(String msg) { 4. System.out.println("RoundPeg insertIntoHole(): " + msg); 5. } 6. } 7. // The SquarePeg class. 8. public class SquarePeg implements ISquarePeg { 9. public void insert(String str) { 10. System.out.println("SquarePeg insert(): " + str); 11. } 12. }

34. CS@UML By Dr. Xinwen Fu34 PegAdapter 1. /** 2. * The PegAdapter class. 3. * This is the two-way adapter class. 4. */ 5. public class PegAdapter implements ISquarePeg, IRoundPeg { 6. private RoundPeg roundPeg; 7. private SquarePeg squarePeg; 8. public PegAdapter(RoundPeg peg) {this.roundPeg = peg;} 9. public PegAdapter(SquarePeg peg) {this.squarePeg = peg;} 10. public void insert(String str) {roundPeg.insertIntoHole(str);} 11. public void insertIntoHole(String msg){squarePeg.insert(msg);} 12. }

35. CS@UML By Dr. Xinwen Fu35 Client 1. // Test program for Pegs. 2. public class TestPegs { 3. public static void main(String args[]) { 4. // Create some pegs. 5. RoundPeg roundPeg = new RoundPeg(); 6. SquarePeg squarePeg = new SquarePeg(); 7. // Do an insert using the square peg. 8. squarePeg.insert("Inserting square peg..."); 9. // Create a two-way adapter and do an insert with it. 10. ISquarePeg roundToSquare = new PegAdapter(roundPeg); 11. roundToSquare.insert("Inserting round peg..."); 12. // Do an insert using the round peg. 13. roundPeg.insertIntoHole("Inserting round peg..."); 14. // Create a two-way adapter and do an insert with it. 15. IRoundPeg squareToRound = new PegAdapter(squarePeg); 16. squareToRound.insertIntoHole("Inserting square peg..."); 17. } 18. }

36. CS@UML By Dr. Xinwen Fu36 Reference 1. Java Design Patterns At a Glance, November 30, 2009 Java Design Patterns At a Glance 2. Allen Holub, Allen Holub's UML Quick Reference, Version 2.1.2, 2007/08/10Allen Holub's UML Quick Reference 3. Laurent Grégoire, UML Quick Reference Card, 2001UML Quick Reference Card 4. UML ® Resource Page, 2009 UML ® Resource Page 5. Randy Miller, Practical UML: A Hands-On Introduction for Developers, 2009Practical UML: A Hands-On Introduction for Developers 6. Design Patterns (with C++, C#, Java, PHP, and Delphi examples), 2011 Design Patterns

37. CS@UML By Dr. Xinwen Fu37 Types of Software Patterns  Analysis: Conceptual models Capture an abstraction of a situation that can often be encountered in modeling  Design: A solution to a problem in a context  Organizational: Recurring structures of relationship, usually in a professional organization, that help the organization achieve its goals  Process: Common template for software development process  Project Planning: Part of project management Relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment  Configuration Management: a field of management Focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life

38. CS@UML By Dr. Xinwen Fu38

39. CS@UML 39 UML Part II  Introduction to UML  Use Case Diagrams  Class Diagrams  Modeling Behavior and Sequence Diagrams

40. CS@UML 40 Objectives of UML  UML is the result of an effort to simplify and consolidate the large number of OO development methods and notations  UML is a general purpose notation that is used to visualize, specify, construct, and document the artifacts of a software system

41. CS@UML Why do We Need Virtual functions? 1. class Base { 2. protected: 3. public: 4. const char* GetName() { return "Base"; } 5. }; 6. 7. class Derived: public Base { 8. public: 9. const char* GetName() { return "Derived"; } 10. }; 11. 12. int main() { 13. Derived cDerived; 14. Base &rBase = cDerived; 15. cout << "rBase is a " << rBase.GetName() << endl; 16. } 41

42. CS@UML Virtual functions 1. class Base { 2. protected: 3. 4. public: 5. virtual const char* GetName() { return "Base"; } 6. }; 7. 8. class Derived: public Base { 9. public: 10. virtual const char* GetName() { return "Derived"; } 11. }; 12. 13. int main() { 14. Derived cDerived; 15. Base &rBase = &cDerived; 16. cout << "rBase is a " << rBase.GetName() << endl; 17. 18. return 0; 19. } 42

43. CS@UML Pure virtual function (abstract function)  A pure virtual function (or abstract function) that has no body at all  When we add a pure virtual function to our class, we are effectively saying, “it is up to the derived classes to implement this function”. 1. class Base { 2. public: 3. // a normal non-virtual function 4. const char* SayHi() { return "Hi"; } 5. 6. // a normal virtual function 7. virtual const char* GetName() { return "Base"; } 8. 9. virtual int GetValue() = 0; // a pure virtual function 10. }; 43

44. CS@UML Consequences of Using Pure Virtual Function  First, any class with one or more pure virtual functions becomes an abstract base class which means that it can not be instantiated!  Second, any derived class must define a body for this function, or that derived class will be considered an abstract base class as well 44

45. CS@UML Interface classes  An interface class is a class that has no members variables, and where all of the functions are pure virtual!  In other words, the class is purely a definition, and has no actual implementation.  Interfaces are useful when you want to define the functionality that derived classes must implement, but leave the details of how the derived class implements that functionality entirely up to the derived class. 45

46. CS@UML Example of Interface Class 1. class IErrorLog 2. { 3. virtual bool OpenLog(const char *strFilename) = 0; 4. virtual bool CloseLog() = 0; 5. 6. virtual bool WriteError(const char *strErrorMessage) = 0; 7. }; 46

47. CS@UML 47 A Class in UML Class name Attribute Operator Mark Visibility type +Public #Protected -Private ~Package  Class name: Must have, other two are optional  Attribute format name : attribute type = default value  Operation (method) format Name(paramater list): return type

48. CS@UML 48 Object Diagram object name : class

49. CS@UML 49 Class Relationships in UML  Inheritance An inheritance link: triangle pointing to superclass  Association A relationship between instances of the two classes Two ends: an end can have a role name to clarify the nature of the association The number of possible instances of the class associated with a a single instance at the other end  Dependency One depends on another if changes in the other could possibly force changes in the first

50. CS@UML 50 Generalization An is-a relationship Abstract class

51. CS@UML 51 UML 2.0: Interface

52. CS@UML 52 Association  Structural relationship between peer classes (or objects)  Association can have a name and direction (indicated by an open arrowhead), or be bi-directional (solid line)  Role names for each end of the association  Multiplicity of the relationship

53. CS@UML 53 Examples of Association  Bi-directional association  Uni-directional association

54. CS@UML 54 Complicated Association: Aggregation and Composition  Basic aggregation is a shared containment. Many other classes may have the same type of aggregate. E.g., string, list  Composition is aggregates that can not stand by themselves (e.g., foot, arm, etc)

55. CS@UML 55 Dependency  Represents a using relationship  If a change in specification in one class effects another class (but not the other way around) there is a dependency  In an e-commerce application, a Cart class depends on a Product class because the Cart class uses the Product class as a parameter for an add operation. In a class diagram, a dependency relationship points from the Cart class to the Product class. The Cart class is the client, and the Product class is the supplier Product

56. CS@UML 56 Dependency Example  Here is a simple rule for when a dependency occurs. If the code for one class contains the name of another class in the diagram, and no other connection exists in the diagram between them then there should be a dashed dependency arrow from the first to the second class 1. class A 2. {public: B returns_a_B(); 3. void has_a_B_argument(B); 4. void has_a_B_in_its_implementation(); 5. }; 6. A::void has_a_B_in_its_implementation(){ B b; }

57. CS@UML 57 Which Relation is Right?  Aggregation – aka is-part-of, is-made-of, contains  Do not confuse part-of (aggregation) with is-a (generation)