1. © Bennett, McRobb and Farmer 2005 1 Design Patterns Based on Chapter 15 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2 nd Edition), McGraw Hill, 2005.

2. © Bennett, McRobb and Farmer 2005 2 In This Lecture You Will Learn:  what types of patterns have been identified in software development  how to apply design patterns during software development  the benefits and difficulties that may arise when using patterns

3. © Bennett, McRobb and Farmer 2005 3 Patterns n Are problem-centred, not solution- centred n Are Discovered, not invented - they already exist n Complement existing techniques and do not replace them n Capture and communicate “best practice” and expertise

4. © Bennett, McRobb and Farmer 2005 4 Application of Patterns n Applied to software design since early 90’s n Now used in in: –Project management –Organisation structures –Requirements analysis –System design –General modelling approaches –Programming – (called idioms) –...

5. © Bennett, McRobb and Farmer 2005 5 Origin of Patterns n Christopher Alexander applied patterns to architecture in the mid-70s n His book “A Pattern Language” is a catalogue of 253 patterns n These document how to construct rooms, buildings and whole communities that people would like to live and work in

6. © Bennett, McRobb and Farmer 2005 6 Software Pattern Definitions n A pattern is proven solution to a problem that recurs in a particular context. n A useful discussion of the possible definitions of a pattern can be found at http://hillside.net/patterns/definition.html

7. © Bennett, McRobb and Farmer 2005 7 Patterns vs. Frameworks n Frameworks are partially completed software systems that may be targeted at a specified type of application n However patterns –are more abstract and general than frameworks –cannot be directly implemented in a particular software environment –are more primitive than frameworks

8. © Bennett, McRobb and Farmer 2005 8 Catalogues & Languages n A pattern catalogue is a group of patterns that are related to some extent and may be used together or independently of each other n The patterns in a pattern language are more closely related, and work together to solve problems in a specific domain

9. © Bennett, McRobb and Farmer 2005 9 Key Principles n Key principles that underlie patterns –abstraction –encapsulation –information hiding –modularization –separation of concerns

10. © Bennett, McRobb and Farmer 2005 10 Key Principles –coupling and cohesion –sufficiency –completeness and primitiveness –separation of policy and implementation –separation of interface and implementation –single point of reference –divide and conquer Buschmann et al. (1996)

11. © Bennett, McRobb and Farmer 2005 11 Non-functional Properties n Buschmann et al. (1996) identify the important non-functional properties of a software architecture n changeability n interoperability n efficiency n reliability n testability n reusability

12. © Bennett, McRobb and Farmer 2005 12 Pattern Template n Name - meaningful that reflects the knowledge embodied by the pattern n Problem - description of the problem that the pattern addresses (the intent of the pattern). Context - represents the circumstances or preconditions under which it can occur. n Forces - embodied in a pattern are the constraints or issues that must be addressed by the solution n Solution - description of the static and dynamic relationships among the components of the pattern

13. © Bennett, McRobb and Farmer 2005 13 Other aspects of Templates n An example of the use of a pattern that serves as a guide to its application n The context that results from the use of the pattern n The rationale that justifies the chosen solution n Related patterns

14. © Bennett, McRobb and Farmer 2005 14 Other aspects of Templates n Known uses of the pattern that validate it (some suggest that until the problem and its solution have been used successfully at least three times—the rule of three—they should not be considered as a pattern) n A list of aliases for the pattern (‘also known as’ or AKA) n Sample program code and implementation details (commonly used languages include C++, Java and Smalltalk)

15. © Bennett, McRobb and Farmer 2005 15 GOF Design Patterns n Catalogue of 23 design patterns presented by Gamma et al. (1995) patterns known as Gang of Four – hence GOF Patterns n Classified as creational, structural or behavioural n Typically address issues concerning changeability involves several different aspects maintainability, extensibility, restructuring and portability

16. © Bennett, McRobb and Farmer 2005 16 Creational Patterns n Concerned with the construction of object instances n Separate the operation of an application from how its objects are created n Gives the designer considerable flexibility in configuring all aspects of object creation

17. © Bennett, McRobb and Farmer 2005 17 Creational Patterns: Singleton n How does one ensure that only one instance of the company class is created? Company companyName companyAddress companyRegistrationNumber getCompanyDetails ()

18. © Bennett, McRobb and Farmer 2005 18 Creational Patterns: Singleton n Solution – restrict access to the constructor! Company - companyInstance - companyName - companyAddress - companyRegistrationNumber + getCompanyInstance() + getCompanyDetails() Class-scope (or static) attribute (or static) operation - Company() Private constructor The use of class-scope operations allows global access Class-scope

19. © Bennett, McRobb and Farmer 2005 19 Singleton: Sequence Diagram :RequestingObject Company singleInstance :Company [else] sd Get company name for display [companyInstance == null] alt getCompanyInstance getCompanyName companyInstance = Company displayName = getCompanyName companyInstance = getCompanyInstance companyInstance = getCompanyInstance

20. © Bennett, McRobb and Farmer 2005 20 Creational Patterns: Singleton Company - companyInstance - companyName - companyAddress + getCompanyInstance() + getCompanyDetails() - Company() + getCompanyDetails():String - UkCompany():UkCompany - companyRegistrationNumber UKCompany + getCompanyDetails():String - USACompany():USACompany - companyRegistrationNumber USACompany + getCompanyDetails():String - FrenchCompany():FrenchCompany - companyRegistrationNumber FrenchCompany The attribute companyRegistrationNumber has been moved to the subclasses where it is defined differently in each. The operation getCompanyDetails() has been moved to the subclasses where it is polymorphically redefined in each. Different subclasses of Company can be instantiated as needed, depending on run-time circumstances

21. © Bennett, McRobb and Farmer 2005 21 Creational Patterns: Singleton + getInstance() Singleton - uniqueInstance - singletonData + getSingletonData() + singletonOperation() - Singleton() Holds object identifier for the Singleton instance Returns object identifier for the unique instance Private constructor — only accessible via getInstance() General form of Singleton pattern

22. © Bennett, McRobb and Farmer 2005 22 Singleton: Template Collaboration Singleton This labels the role that is played by the class Company in this collaboration Collaboration name singleton class Lists the types of the roles that are involved in this collaboration singleton class Company

23. © Bennett, McRobb and Farmer 2005 23 Structural Patterns n Concerned with the way in which classes and objects are organized n Offer effective ways of using object- oriented constructs such as inheritance, aggregation and composition to satisfy particular requirements

24. © Bennett, McRobb and Farmer 2005 24 Structural Patterns: Composite MediaClip play() VideoClip play() SoundClip play() How can we present the same interface for a media clip whether it is composite or not?

25. © Bennett, McRobb and Farmer 2005 25 Structural Patterns: Composite Delegates to the play() operation in the components. play() is polymorphically redefined VideoClip play() SoundClip play() AdSequence play() addClip() removeClip() getChild() * * 1 How can we incorporate composite structures?

26. © Bennett, McRobb and Farmer 2005 26 Composite applied to Agate Collection of MediaClip object identifiers for all m in mediaClipCollection m.play() Delegates to the play() operation in the components. play() is polymorphically redefined AdSequence mediaClipCollection play() addClip() removeClip() getChild() changeSequence() * 1 MediaClip play() addClip() removeClip() getChild() VideoClip play() SoundClip play() Advert {ordered}

27. © Bennett, McRobb and Farmer 2005 27 Template collaboration for Composite Pattern Composite CompositeClassType ComponentClassType LeafClassType Composite :CompositeClassType LeafClass :LeafClassType ComponentClass :ComponentClassType

28. © Bennett, McRobb and Farmer 2005 28 Collaboration for Composite Pattern MediaClip Composite composite class component class leaf class AdSequence SoundClip VideoClip component class composite class leaf class

29. © Bennett, McRobb and Farmer 2005 29 Composite Structure Diagram for Composite Pattern «collaboration» Composite Leaf Component sd Composite

30. © Bennett, McRobb and Farmer 2005 30 Composite Pattern: Sequence Diagram :AdSequence clip[i] :MediaClip sd Play advert sequence [i<=mediaClipCollection. size()] play loop (1,*) play

31. © Bennett, McRobb and Farmer 2005 31 Composite Pattern General Form Collection of Component object identifiers for all c in componentCollection c.anOperation() anOperation() is polymorphically redefined Composite componentCollection anOperation() addComponent() removeComponent() getChild() * 1 Component anOperation() addComponent() removeComponent() getChild() Leaf anOperation() OtherLeaf anOperation() Client

32. © Bennett, McRobb and Farmer 2005 32 Behavioural Patterns n Address the problems that arise when assigning responsibilities to classes and when designing algorithms n Suggest particular static relationships between objects and classes and also describe how the objects communicate

33. © Bennett, McRobb and Farmer 2005 33 Behavioural Patterns: State Consider the class Campaign. n It has four states – Commissioned, Active, Completed and Paid n A Campaign object has different behaviour depending upon which state it occupies. n Operations have case statements giving this alternative behaviour n The class factored into separate components – one for each of its states

34. © Bennett, McRobb and Farmer 2005 34 Campaign class: could have state pattern applied If commissioned then... If active then... If completed then... If paid then... Illustrative Structured English for the calcCosts() operation «entity» Campaign - title - campaignStartDate - campaignFinishDate - estimatedCost - completionDate - datePaid - actualCost - campaignOverheads - advertCollection - teamMembers + Campaign() + assignManager() + assignStaff() + checkCampaignBudget() + calcCosts() + checkStaff() + getDuration() + getTeamMembers() + linkToNote() + addAdvert() + listAdverts() + recordPayment() + getCampaignDetails() - getOverheads() + completeCampaign()

35. © Bennett, McRobb and Farmer 2005 35 Behavioural Patterns: State State pattern applied to the class Campaign Contains the object identifier of the current state object CampaignState addAdvert() calcCosts() completeCampaign() Commissioned addAdvert() calcCosts() completeCampaign() Campaign currentStateIdentifier addAdvert() changeState() calcCosts() changeState() completeCampaign() Active addAdvert() calcCosts() completeCampaign() Completed addAdvert() calcCosts() completeCampaign() Paid addAdvert() calcCosts() completeCampaign()

36. © Bennett, McRobb and Farmer 2005 36 Behavioural Patterns: State Some State pattern objects for Agate – note that there are 6 Campaign objects sharing the four State objects. a:Campaign c:Campaign e:Campaignb:Campaign f:Campaign d:Campaign :Commissioned :Active :Completed :Paid

37. © Bennett, McRobb and Farmer 2005 37 Template Collaboration for State Pattern State context class state class concrete state class CampaignState Commissioned Active Completed Paid Campaign concrete state class state class

38. © Bennett, McRobb and Farmer 2005 38 State Pattern: Sequence Diagram sd Set campaign completed :Campaign :Active completeCampaign changeState(nextState) completeCampaign

39. © Bennett, McRobb and Farmer 2005 39 General form of State Pattern State operation() ConcreteStateA operation() ConcreteStateB operation() Context operation()

40. © Bennett, McRobb and Farmer 2005 40 Before Using Patterns n Before using a pattern to resolve the problem ask –Is there a pattern that addresses a similar problem? –Does the pattern trigger an alternative solution that may be more acceptable? –Is there a simpler solution? Patterns should not be used just for the sake of it

41. © Bennett, McRobb and Farmer 2005 41 Before Using Patterns –Is the context of the pattern consistent with that of the problem? –Are the consequences of using the pattern acceptable? –Are constraints imposed by the software environment that would conflict with the use of the pattern?

42. © Bennett, McRobb and Farmer 2005 42 Using Patterns n After selecting a suitable pattern 1.Read the pattern to get a complete overview 2.Study the Structure, Participants and Collaborations of the pattern in detail 3.Examine the Sample Code to see an example of the pattern in use

43. © Bennett, McRobb and Farmer 2005 43 Using Patterns 4.Choose names for the pattern’s participants (i.e. classes) that are meaningful to the application 5.Define the classes 6.Choose application specific names for the operations 7.Implement operations that perform the responsibilities and collaborations in the pattern

44. © Bennett, McRobb and Farmer 2005 44 Summary In this lecture you have learned about:  what types of patterns have been identified in software development  how to apply design patterns during software development  the benefits and difficulties that may arise when using patterns

45. © Bennett, McRobb and Farmer 2005 45 References n Gamma et al. (1995) (For full bibliographic details, see Bennett, McRobb and Farmer)