6 DESIGN PATTERNS  6/11/97

6 Design Patterns

6.1 What are patterns, and why?

Design Patterns

“Reuse of good ideas”

A pattern is a named, well understood good solution to a common problem.

Idea comes from architecture: e.g. Window Place: observe that people need comfortable places to sit, and like being near windows, so make a comfortable seating place at a window.

Similarly, there are many commonly arising technical problems in software design.

Experienced designers recognise them and understand how to solve them. Without patterns, novices have to find solutions from first principles.

Patterns help novices to learn by example to behave more like experts.

Pattern catalogues: for easy reference, and to let designers talk shorthand.

Slide 51

The point is that you get to spend your effort on building the best solution, whereas if you have to start from scratch you may have to spend a significant amount of time hunting for any solution at all: and you may not spot disadvantages of a solution until you get bitten by them. Patterns let you stand on the shoulders of giants.

Patterns are almost by definition not new: they document, at a suitable level of abstraction, designs which are already tried, tested and well understood. Experienced designers probably already know most if not all of the standard ones, and if you read either of the recommended books there will be patterns that you’ve used, I’m sure.

Even if you already recognise the techniques used in a pattern and are confident you would essentially have used it in appropriate circumstances anyway, it’s still useful to have a good, abstracted description. It makes it easier to spot improvements and variants: and the handle that a name with a commonly agreed meaning provides makes it easier to discuss designs.

Patterns exist at many levels: Buschmann et al distinguish between architectural patterns (such as layered architecture, and MVC which we’ll look at) at the highest level, design patterns (such as Publisher-Subscriber, which we’ll study) in the middle, and idioms at the programming level. Confusingly all three of these levels are included in what most of the patterns community calls design patterns.

We’ll study one very simple pattern in detail, and then look at how it is incorporated in a more complicated framework, which we won’t cover in detail.

6.2 Example: Publisher-Subscriber

6 DESIGN PATTERNS  6/11/97  6.2 Example: Publisher-Subscriber

One common problem

It often happens that when one object changes state, one or more other objects need to know about it so that their states remain consistent. E.g. one or more elemements of a user interface need to show the correct version of some data item, part of the state of an object (say aCustomer) inside the system. We could introduce explicit dependencies, and have the changing object notify its dependants by sending them messages: but this is inflexible and prevents reuse (e.g. of aCustomer). User interfaces are very prone to change, so internal objects shouldn’t know what the user interface is like. We could have the dependants poll the changing object to see when it changes: but this is very inefficient. May well want to add or remove dependants at run time.

Slide 52

Class diagram

Slide 53

6 DESIGN PATTERNS  6/11/97  6.3 Pattern catalogues

Sequence diagram, 2 subscribers

Slide 54

6.3 Pattern catalogues

Rather than giving general instructions about what constitutes good design, a pattern catalogue documents particular designs that are useful in certain contexts. One of the main challenges for the patter writer is to get the level of abstraction, at which the pattern is described, right: it must be abstract enough to be applicable to as large a family of situations as possible, but not so abstract as to be platitudinous. (Unfortunately even the experts don’t always get this right: it’s harder the larger the scale of the pattern.)

Pattern catalogues have to be easy and quick to refer to. A common format for describing patterns helps here. There’s a role for UML here too: the existing patterns books each use their own notation, usually some form of OMT-like class diagram and sequence diagrams like UML’s. In future, assuming UML really does become the standard modelling language, we may expect pattern catalogues to describe patterns using it, so that you will be able to expect not to have the language barrier imposed by the need to understand different notations in different books.

UML in fact includes the possibility of using patterns explicitly in class models: the pattern name is shown inside a dotted oval, with dotted lines joining the oval which represents the pattern to the class rectangles which represent the classes taking roles in the pattern. The lines are labelled by role names. So for example, if your design uses Publisher-Subscriber with objects of class Customer as the Publisher and objects of class CustomerView as the Subscribers, you’d show something like this:

As you see from my xfig’d diagram, Rose does not support this notation.

6 DESIGN PATTERNS  6/11/97  6.4 Patterns in context: MVC

If you do use patterns, by name without explaining them, as part of your design, it is of course important to have an agreed “vocabulary” of patterns which can be used in this way! This might be agreed at the team level or the organisation level. Probably you would name one or two pattern catalogues whose patterns could be used without description: one would almost certainly be Gamma et al.; I’ve already seen their patterns referred to by other papers in the expectation that the readers will know them. Possibly an organisation might build up its own collection of patterns as well as agreeing on standard ones: but I have a suspicion that the need to do this might be a sign that the patterns are being described at too low a level of abstraction. I doubt that genuinely commonly occurring design problems are really domain-specific. This really remains to be seen.

Elements of a pattern

A pattern catalogue entry normally includes these elements:

• Name (e.g. Publisher-Subscriber)

• Aliases (e.g. Observer, Dependants)

• Context (in what circumstances can the problem arise?)

• Problem (see slide above)

• Solution (see slides above: normally a mixture of text and models)

• Consequences (good and bad things about what happens if you use the pattern.)

The elements aren’t always named in this way. GoF lump context and problems together, Buschmann et al don’t have a separate consequence section.

It may contain more, e.g. variations, CRC cards, example code.

Slide 55

6.4 Patterns in context: MVC

In this section we consider the Model-View-Controller user interface architecture. We do not go into full detail even of MVC, let alone of the motivations for using it or not. It would be quite reasonable to have an entire course on the software engineering of user interfaces, but this course isn’t it!

There are two reasons for looking at MVC:

1. to show a more complex pattern

2. to show a technique for building a UI onto an OO system, and to make it clear “how the whole thing is started up”, which some people were justificably confused about when we studied the CS4 admin system.

User interfaces: hard problems

Why? They’re very visible: all errors matter. They’re prone to changes in requirements. They often have to exist on different platforms. They’re complicated. They’re often not just text. And we haven’t mentioned usability yet... OO and GUIs have grown popular together: OO techniques for GUIs have a long history. Building on Publisher-Subscriber, we’ll briefly consider Model-View-Controller, a framework which originated in Smalltalk-80 (cf InterViews). More (e.g. Presentation-Abstraction-Control) and less (e.g. Document-View, Model-Pane-Dispatcher) sophisticated OO techniques exist. So do non-OO techniques, e.g. Seeheim model: and one can build hybrids.

Slide 56

MVC in brief

The Model is the core of the application: e.g. the CS4 admin system. It is independent of the user interface. Their is one Controller for each View; there may be many pairs for one Model. Between them Views and Controllers are the UI. View components control how data from the model is presented to the user. A View normally creates and initialises its Controller. Controller components accept user input (as events from the X event handling mechanism, or whatever) and do the right thing. There may be compositional hierarchies of them (using the pattern Composition), but we’ll ignore that for simplicity here.

Slide 57

6 DESIGN PATTERNS  6/11/97  6.4 Patterns in context: MVC

MVC class model

Slide 58

MVC handling an event

Slide 59

The controller normally reacts to user input by invoking public methods on the model. (For example, if the user presses a button or whatever that is supposed to mean “get me the course handbook material for this honours course”, the controller reacts to the button press

\overline{SEOC97  Id : notes8.tex, v1.41997/11/0815 : 18 : 20pxsExppxs  62}

by sending message getDescriptions to the correct HonoursCourse object. Notice from this that of course the UI does have to know about the model! It’s the reverse direction we’re trying to avoid. Sometimes, however, the user input will be invoking functionality which is independent of the model – scrolling, for example – in which case the controller may instead send message directly to the view.

The view and its controller are quite tightly coupled, and for this reason some variants on MVC, like Document-View used in Visual C++, combine them into one class. On the other hand it is possible to swap the controller of a view for another, and sometimes useful: for example, to inactivate an interface component you might swap its controller for one that ignores all input.

There are also other patterns that help in building generic controllers e.g. to do the right thing with selection lists: when you use such a controller, you configure it with which message it should send to the model under what circumstances.

It’s clear that Views have to be Subscribers in the Publisher-Subscriber pattern, with the Model as the Publisher. We’ve also shown Controllers being possible Subscribers to the Model. This is because certain kinds of interaction may only sometimes be available: for example, the state of the model may determine whether a menu item is greyed out, so then the controller needs to know when the state changes. (Yes, there’s a grey area connected with exactly what’s the responsibility of the View and what of the Controller.)

In the beginning

A small amount of setup code – outside even the model:

1. creates and initialises the model

2. creates and initialises the views, setting up the association with the model (e.g. by passing a reference to it). On initialisation:

• The views create and initialise their controllers, which

• register interest in whatever events they want

3. starts event processing, using XtMainLoop() or whatever.

From then on, the event processing loop feeds user input events to the controller... and it Just Works.

If our application has many controllers at different levels of abstraction, there is work to be done to get the event passed down to the Controller at the correct level of abstraction: but it’s generic. Toolkits help.

Slide 60

New references

For links to patterns-related material, see my software engineering links page – there’s a link to that from the course home page.

• Gamma, E., Help, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Professional Computing series, 1994.

This is the Gang of Four book, the most famous and important pattern book to date.

• Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. A System of Patterns: Pattern-Oriented Software Architecture Wiley

Also good: more patterns in less detail.

• Fowler, M. Analysis Patterns: Reusable Object Models Addison-Wesley 1997 I don’t own this one, but it’s by the same person who wrote UML Distilled. It’s probably good!