91.204.201 Computing IV

1
91.204.201 Computing IV

• Introduction to Design Pattern
• Xinwen Fu

2
Outline

• Introduction to Pattern
• Gang of Four Design Pattern
• Adapter Pattern
• Introduction to UML

3
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
Pattern of Porches
Classical House Styles
American Colonial Styles
Spanish and Mediterranean
Victorian House Styles
5
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
Software Patterns History

• 1987 - Cunningham and Beck used Alexanders 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
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
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
Outline

• Introduction to Pattern
• Gang of Four Design Pattern
• Adapter Pattern
• Introduction to UML

10
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
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
Purpose Design Pattern Aspect(s) That Can Vary
Creational Abstract 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
Structural Adapter (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
Behavioral Chain 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
Online Materials

• Design Patterns
• Erich Gamma, Richard Helm, Ralph Johnson, and
  John Vlissides, Design Patterns Elements of
  Reusable Object-Oriented Software, Addison
  Wesley. October 1994.

14
Iterator
15
Outline

• Introduction to Pattern
• Gang of Four Design Pattern
• Adapter Pattern
• Introduction to UML

16
C Example

1. include ltiostream.hgt
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
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

1. void oldDraw()
2. cout ltlt "LegacyRectangle oldDraw. ("
   ltlt x1_ ltlt "," ltlt y1_ ltlt
3. ") gt (" ltlt x2_ ltlt "," ltlt y2_ ltlt ")" ltlt
   endl
5. private
6. Coordinate x1_
7. Coordinate y1_
8. Coordinate x2_
9. Coordinate y2_
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 ltlt "RectangleAdapter create. (" ltlt
    x ltlt "," ltlt y ltlt
17. "), width " ltlt w ltlt ", height " ltlt
    h ltlt endl

18
Understanding the Start of an Object's Lifetime

1. include ltiostreamgt
2. class Foo
3. public
4. Foo() stdcout ltlt "Foo's constructor"
   ltlt stdendl
6. class Bar public Foo
7. public
8. Bar() stdcout ltlt "Bar's constructor"
   ltlt stdendl
10. int main()
11. // a lovely elephant )
12. Bar bar

19
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
Outline

• Introduction to Pattern
• Gang of Four Design Pattern
• Adapter Pattern
• Introduction to UML

21
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
Class Adapter

• A class adapter uses multiple inheritance to
  adapt one interface to another

23
Object Adapter

• An object adapter relies on object composition

24
Outline

• Introduction to Pattern
• Gang of Four Design Pattern
• Adapter Pattern
• Introduction to 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
A Class in UML

• Class name Must have, other two are optional
• Attribute format
• name attribute type default value
• Operation (method) format
• Name(paramater list) return type

Mark Visibility type
Public
Protected
- Private
Package
Class name
Attribute
Operator
27
Object Diagram
object name class
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
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.
• Youtube videos on UML

30
Backup
31
(No Transcript)
32
Two-Way Adapter Example in Java

• Here are the interfaces for round and square
  pegs
• /
• The IRoundPeg interface.
• /
• public interface IRoundPeg
• public void insertIntoHole(String msg)
• /
• The ISquarePeg interface.
• /
• public interface ISquarePeg
• public void insert(String str)

33
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)
7. // The SquarePeg class.
8. public class SquarePeg implements ISquarePeg
9. public void insert(String str)
10. System.out.println("SquarePeg insert() "
    str)

34
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)

35
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)

36
Reference

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

37
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
(No Transcript)
39
UML Part II

• Introduction to UML
• Use Case Diagrams
• Class Diagrams
• Modeling Behavior and Sequence Diagrams

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
Why do We Need Virtual functions?

1. class Base
2. protected
3. public
4.    const char GetName() return "Base"
6.  
7. class Derived public Base
8. public
9.     const char GetName() return "Derived"
11.  
12. int main()
13.     Derived cDerived
14.     Base rBase cDerived
15.     cout ltlt "rBase is a " ltlt rBase.GetName() ltlt
    endl

42
Virtual functions

1. class Base
2. protected
3.  
4. public
5.     virtual const char GetName() return
   "Base"
7.  
8. class Derived public Base
9. public
10.     virtual const char GetName() return
    "Derived"
12.  
13. int main()
14.     Derived cDerived
15.     Base rBase cDerived
16.     cout ltlt "rBase is a " ltlt rBase.GetName() ltlt
    endl
17.  
18.     return 0

43
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.
• class Base
• public
• // a normal non-virtual function
• const char SayHi() return "Hi"
• // a normal virtual function
• virtual const char GetName() return
  "Base"
• virtual int GetValue() 0 // a pure virtual
  function

44
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

45
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.

46
Example of Interface Class

1. class IErrorLog
3. virtual bool OpenLog(const char strFilename)
   0
4. virtual bool CloseLog() 0
6. virtual bool WriteError(const char
   strErrorMessage) 0

47
A Class in UML

• Class name Must have, other two are optional
• Attribute format
• name attribute type default value
• Operation (method) format
• Name(paramater list) return type

Mark Visibility type
Public
Protected
- Private
Package
Class name
Attribute
Operator
48
Object Diagram
object name class
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
Generalization

• An is-a relationship
• Abstract class

51
UML 2.0 Interface
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
Examples of Association

• Bi-directional association
• Uni-directional association

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
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

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
• class A
• public B returns_a_B()
• void has_a_B_argument(B)
• void has_a_B_in_its_implementation()
• Avoid has_a_B_in_its_implementation() B b

57
Which Relation is Right?

• Aggregation aka is-part-of, is-made-of,
  contains
• Do not confuse part-of (aggregation) with is-a
  (generation)