21
Design Patterns Ref : Chapter 15 Bennett et al

Design Patterns

Embed Size (px)

DESCRIPTION

Design Patterns. Ref : Chapter 15 Bennett et al.  useful groups of collaborating classes that provide a solution to commonly occuring problems. provide a means for capturing knowledge about problems and successful solutions. vs. Patterns. Frameworks. - PowerPoint PPT Presentation

Citation preview

Design Patterns

Ref : Chapter 15 Bennett et al

• useful groups of collaborating classes that provide a solution to commonly occuring problems.

• provide a means for capturing knowledge about problems and successful solutions.

vsPatterns• More abstract that

frameworks • description of the way a

type of problem can be solved, but not in themselves solutions, as they can’t be directly implemented.

• They are more primitive than frameworks

Frameworks

• Frameworks (e.g. .net framework, xna)

• Partially completed software systems that may be targeted at a specific type of application.

• Re-usable mini architectures.

• Can be customised by specialisation of classes, add-in operations and classes.

A Pattern Catalogue• Lists commonly used design patterns using pattern

templates

• Problem – describes the problem• Context – describes how it occurs• Forces – constraints or issues that must be addressed by

solution• Solution – describes solution approaches

• Code fragments – show how the solution can be implemented in code

E.g. see http://www.dofactory.com/Patterns/Patterns.aspx

Example• Whole-part pattern – specifically supports

aggregation and composition relationships in UML (see page 334).

• Gang of Four (GOF) developed sets of design patterns and guidelines for their use.

• (Gamma Helm Johnston and Vlissides)

Client Whole

Service_1Service_2

Part 2

Service_b1Service_b2

Part 1

Service_a1Service a_2

• Scope of a pattern: class level (static- relationships) or object level (dynamic)

• Patterns are based on principles of good design: maximise encapsulation/ using composition– Maintainability– Extensibility– Restructuring– portability

3 Types of Design Pattern (GOF)• Creational –concerned with how objects are

constructed

• Structural- address issues concerned with the way classes and objects are organised.

• Behavioural- describe how objects communicate

• See c# examples on ...http://www.dofactory.com/Patterns/Patterns.aspx

Example Creational Pattern:Singleton• Problem: Ensure a class has only one instance and provide a global

point of access to it.e.g. In water safety we only want one Water safety Authority object,

which needs global access.

Solution:• Make the constructor private• Have a get_instance method to either create the object or return

the object reference.

Class singleton

_uniqueinstance-singletondata

+get_instance+getdata-singleton

C# implementationclass Singleton { private static Singleton _instance; // Constructor is 'protected‘ not public as usual protected Singleton() { } public static Singleton Instance() { if (_instance == null) { _instance = new Singleton(); } return _instance; } }http://www.dofactory.com/Patterns/Patterns.aspxNote this is not thread safe.

Structural Pattern example: Composite

• Problem: to represent whole-part hierarchies so that both offer the same interface to client objects.

• Context : Both composite and component objects exist and should be treated in the same way.

• Solution : Combine inheritance and aggregation hierarchies. Compose objects into tree structures to represent part-whole hierarchies.

See figs 15.10, 15.14 Bennett et al

SoundClip

+play()

Advert

Advert sequence

MediaClipCollection[n]

+play()+addclip()+=removeclip()+getchild()+changesequence()

Media Clip

_uniqueinstance-singletondata

+play()

VideoClip

+play()

* ordered

For all m in MediaClipCollectionm.play()

Source : http://www.dofactory.com/Patterns/Patterns.aspx

Example Behavioural Pattern : state

Problem: operations done differently on an object dependent on its state.

Description: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

• Create additional classes, one for each state so that each holds a state-sepcific version of the operation.

• ‘pure state’ classes contain no attributes, just redefinitions of operations.

• This should only be used for objects with significant state-dependent behaviour, as there is a big code overhead with the extra classes.

Source : http://www.dofactory.com/Patterns/Patterns.aspx

• An object has complex behaviour which is dependent on its STATE

• The original object delegates reponsibility to the appropriate state object

• A changestate() method is sent to the parent who invokes a nextstate method.

Example Behavioural Pattern 2 : Command

• An object is used to encapsulate all the information needed to call a method at a later time:- the method name, the object that owns the method and values for the method parameters.

– client instantiates the command object and provides the information required to call the method at a later time.

– invoker decides when the method should be called. – receiver is an instance of the class that contains the method's code.

• makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.

• Good for allowing undos.

How to use design Patterns• NOT for the sake of it – there are many examples of badly

used patterns.• Analyse problem and context• Ensure that you really understand patterns• Find a pattern that addresses a similar problem, read and

study it and determine whether it gives you a better solution

• Check it there is a simpler solution• Check that the context of the pattern similar to your

problem• Make sure the consequences of using the pattern are

acceptable.• Examine sample code.• Apply and refine.

A pattern.. (hillside.net)• solves a problem: Patterns capture solutions, not

just abstract principles or strategies. • is a proven concept: Patterns capture solutions

with a track record, not theories or speculation. • describes a relationship: Patterns don't just

describe modules, but describe deeper system structures and mechanisms.

• has a significant human component (minimize human intervention). All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.

• A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of related systems.

• The solution isn't obvious: Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. The best patterns generate a solution to a problem indirectly--a necessary approach for the most difficult problems of design.

References

• Chapter 15 Bennett et al explains patterns well and has some good examples.

• Hillside.net has lots of useful links, including a link to several pattern catalogues.

• Dofactory.com has lots of c# examplesand skeletal code.