Design Patterns Based on Chapter 15 Bennett Mc

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 © 2010 Bennett, Mc. Robb and Farmer 2

Patterns • Are problem-centred, not solutioncentred • Are Discovered, not invented - they already exist • Complement existing techniques and do not replace them • Capture and communicate “best practice” and expertise © 2010 Bennett, Mc. Robb and Farmer 3

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

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

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

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

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

Key Principles • Key principles that underlie patterns – abstraction – encapsulation – information

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) © 2010 Bennett, Mc. Robb and Farmer 10

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

Pattern Template • Name - meaningful that reflects the knowledge embodied by the pattern • 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. • Forces - embodied in a pattern are the constraints or issues that must be addressed by the solution • Solution - description of the static and dynamic relationships among the components of the pattern © 2010 Bennett, Mc. Robb and Farmer 12

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

Other aspects of Templates • 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) • A list of aliases for the pattern (‘also known as’ or AKA) • Sample program code and implementation details (commonly used languages include C++, Java and Smalltalk) © 2010 Bennett, Mc. Robb and Farmer 14

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

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

Creational Patterns: Singleton • How does one ensure that only one instance of the company class is created? Company company. Name company. Address company. Registration. Number get. Company. Details() © 2010 Bennett, Mc. Robb and Farmer 17

Creational Patterns: Singleton • Solution – restrict access to the constructor! Company - company. Instance - company. Name - company. Address - company. Registration. Number + get. Company. Instance() + get. Company. Details() - Company() Class-scope (or static) attribute Class-scope (or static) operation Private constructor The use of class-scope operations allows global access © 2010 Bennett, Mc. Robb and Farmer 18

Singleton: Sequence Diagram sd Get company name for display : Requesting. Object alt Company [company. Instance == null] get. Company. Instance Company company. Instance = get. Company. Instance single. Instance : Company company. Instance = Company [else] get. Company. Instance company. Instance = get. Company. Instance get. Company. Name display. Name = get. Company. Name © 2010 Bennett, Mc. Robb and Farmer 19

Creational Patterns: Singleton Company The operation get. Company. Details() has been moved to the subclasses where it is polymorphically redefined in each. - company. Instance - company. Name - company. Address + get. Company. Instance() + get. Company. Details() - Company() The attribute company. Registration. Number has been moved to the subclasses where it is defined differently in each. UKCompany USACompany French. Company - company. Registration. Number + get. Company. Details(): String - Uk. Company(): Uk. Company + get. Company. Details(): String - USACompany(): USACompany + get. Company. Details(): String - French. Company(): French. Company Different subclasses of Company can be instantiated as needed, depending on run-time circumstances © 2010 Bennett, Mc. Robb and Farmer 20

Creational Patterns: Singleton Holds object identifier for the Singleton instance - unique. Instance - singleton. Data + get. Instance() + get. Singleton. Data() + singleton. Operation() - Singleton() Returns object identifier for the unique instance Private constructor — only accessible via get. Instance() General form of Singleton pattern © 2010 Bennett, Mc. Robb and Farmer 21

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

Structural Patterns • Concerned with the way in which classes and objects are organized • Offer effective ways of using objectoriented constructs such as inheritance, aggregation and composition to satisfy particular requirements © 2010 Bennett, Mc. Robb and Farmer 23

Structural Patterns: Composite • How can we present the same interface for a media clip whether it is composite or not? Media. Clip play() Video. Clip Sound. Clip play() © 2010 Bennett, Mc. Robb and Farmer 24

Structural Patterns: Composite How can we incorporate composite structures? Ad. Sequence Delegates to the play() operation in the components. play() add. Clip() remove. Clip() get. Child() play() is polymorphically redefined 1 * * Video. Clip Sound. Clip play() © 2010 Bennett, Mc. Robb and Farmer 25

Composite applied to Agate Advert Media. Clip * {ordered} play() add. Clip() remove. Clip() get. Child() play() is polymorphically redefined 1 Video. Clip Sound. Clip Ad. Sequence media. Clip. Collection play() for all m in media. Clip. Collection m. play() add. Clip() remove. Clip() get. Child() change. Sequence() © 2010 Bennett, Mc. Robb and Farmer Collection of Media. Clip object identifiers Delegates to the play() operation in the components. 26

Template collaboration for Composite Pattern Composite. Class. Type Component. Class. Type Leaf. Class. Type Composite Component. Class : Component. Class. Type Composite : Composite. Class. Type Leaf. Class : Leaf. Class. Type © 2010 Bennett, Mc. Robb and Farmer 27

Collaboration for Composite Pattern composite class component class leaf class Composite component class leaf class Media. Clip Video. Clip composite class Ad. Sequence leaf class Sound. Clip © 2010 Bennett, Mc. Robb and Farmer 28

Composite Structure Diagram for Composite Pattern «collaboration» Composite sd Composite Component Leaf Composite ©

Composite Pattern: Sequence Diagram sd Play advert sequence clip[i] : Media. Clip : Ad.

Composite Pattern General Form Client Component an. Operation() is polymorphically redefined * an. Operation() add. Component() remove. Component() get. Child() 1 Leaf Other. Leaf Composite component. Collection an. Operation() for all c in component. Collection c. an. Operation() add. Component() remove. Component() get. Child() © 2010 Bennett, Mc. Robb and Farmer Collection of Component object identifiers 31

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

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

«entity» Campaign class: could have state pattern applied - title - campaign. Start. Date - campaign. Finish. Date - estimated. Cost - completion. Date - date. Paid - actual. Cost - campaign. Overheads - advert. Collection - team. Members Illustrative Structured English for the calc. Costs() operation + Campaign() + assign. Manager() + assign. Staff() + check. Campaign. Budget() + calc. Costs() + check. Staff() + get. Duration() + get. Team. Members() + link. To. Note() + add. Advert() + list. Adverts() + record. Payment() + get. Campaign. Details() - get. Overheads() + complete. Campaign() © 2010 Bennett, Mc. Robb and Farmer If commissioned then . . . If active then . . . If completed then . . . If paid then . . . 34

Behavioural Patterns: State Campaign current. State. Identifier add. Advert() change. State() calc. Costs() change. State() complete. Campaign() add. Advert() calc. Costs() complete. Campaign() Contains the object identifier of the current state object Commissioned Active Completed Paid add. Advert() calc. Costs() complete. Campaign() State pattern applied to the class Campaign © 2010 Bennett, Mc. Robb and Farmer 35

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

Template Collaboration for State Pattern context class state class concrete state class State context class Paid Campaign concrete state class Completed state class concrete state class Campaign. State Active concrete state class Commissioned © 2010 Bennett, Mc. Robb and Farmer 37

State Pattern: Sequence Diagram sd Set campaign completed : Campaign : Active complete. Campaign

General form of State Pattern Context State operation() Concrete. State. A Concrete. State. B

Before Using Patterns • 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 © 2010 Bennett, Mc. Robb and Farmer 40

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? © 2010 Bennett, Mc. Robb and Farmer 41

Using Patterns 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 © 2010 Bennett, Mc. Robb and Farmer 42

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 © 2010 Bennett, Mc. Robb and Farmer 43

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 © 2010 Bennett, Mc. Robb and Farmer 44