Is This a Pattern

byTiffany WinnPaul Calder

Flinders University of South Australia

The Authors Tiffany Winn is a PhD student in computer science at

Flinders University, where she received her BSc (Hons.) in computer science. Her research interests are in design patterns and programming paradigms.

Paul Calder is a senior lecturer in the School of Informatics & Engineering at Flinders University. His research interests include object-oriented software design, component-based software reuse, graphical interfaces, and data visualization. He is a member of the IEEE Computer Society, ACM SIGCHI, and ACM SIGPLAN. He earned his PhD in electrical engineering from Stanford University, where he was one of the developers of the InterViews user interface toolkit.

Software Design Patterns Identifying pattern

Developers must recognize reoccurring problems

Developers then create a solutions for those problems

Buzz Word Recently the word “pattern” has

become a buzz word

The implicit definition of the pattern concept has become less precise

Developer Skills Developers must increase

Their understanding of patterns at a theoretical and practical level

Their ability to distinguish patterns from similar seeming non-patterns

Essential Characteristics of Patterns These characteristics cannot

provide a definite test for pattern-ness

If an entity does not contain one of the characteristics then it is not a pattern

1. A pattern implies an artifact Big picture level: How the software

works

Design level: The relationships the software attempts to capture

Drawing the artifact The design pattern captures the

overall structure in a physical or spatial sense

If the software pattern cannot be drawn, it does not embody a physical understanding of a software’s artifact and therefore is not a pattern

2. A pattern bridges many levels of abstraction A pattern is not just a concrete designed

artifact or abstract description

A pattern facilitates the progression from a vague idea to the actual software

Therefore a pattern bridges different abstraction levels

Linking abstraction levels Linking helps designers make

connections between different levels Book Analogy:

Story – paragraph – sentence – word

Book Program: Story Level General problem overview Paragraph Level Flowchart (control flow) Sentence Level Algorithms Word Level Sample Code

Flowchart and Algorithms help link the general overview with the sample code

Design aids, such as patterns, should bridge different design levels Designers understanding evolves as the solution

develops

It is important to develop aids that move from gradual initial understanding to a more in depth one

The ability to link different levels of thinking about a design is critical to knowledge reuse

Linking abstraction levels

Knowledge Reuse Knowledge reuse is a key to good design

“The challenge in reusability is to express the fragmentary and abstract components out of which complete programs are built.” *

Designers reuse knowledge by learning from their own and others’ experiences

Recognize and abstract from useful similarities at any abstraction level from their own or others’ context

* C. Rich and R.C. Waters, The Programmers Apprentice. Addison-Wesley, Reading, Mass., 1990

3. A pattern is both functional and nonfunctional Functional issues deal with possibility

Determine what decisions could be or were made in a particular context

Nonfunctional issues deal with feasibility They address the reasons the decision was

made and it’s desirability in a particular context

Balancing Act Design often involves balancing

conflicting forces Sacrificing software readability for efficiency

Good design requires more that understanding just the forces involved

It also requires understanding the relationships between those forces

Design Complexity Software design is complex and

subject to frequent change Complex design – a developer will be

unable to grasp the interplay between forces

Designers must develop skills, methods, and tools that help clarify interplay

Functional and Nonfunctional A design pattern is functional because it

documents a solution to a problem Provide fragment samples of code and

diagrams of software structure

A design patterns is nonfunctional because it discusses the feasibility of the solution documents Discussion of its applicability

4. A pattern is manifest in a solution The pattern will be present and

recognizable in the solution Whether used consciously or

unconsciously

A pattern is not a simple tool … it leaves a mark on the finished product Focuses both on design process and

design structure

Design Approaches All design approaches strive for the

creation of well-designed software Approaches that focus solely on

design process or methodology do no leave any identifiable imprint

Approaches, such as design patterns that focus on both design process and structure directly influence the visible structure of the product

5. A pattern captures system hot spots Software system must remain stable in a

highly dynamic environment

Building a stable system is not about foreseeing every modification

Building a stable system is about understanding the domain well enough to build a system that can evolve appropriately

Invariant and Hot Spots Central to any pattern is an

invariant that solves a reoccurring problem

Patterns facilitate good design by capturing “hot spots” – those parts of a solution likely to change as a development system evolves

Invariant and Hot Spots The pattern captures the invariant and

hot spots and provides a structure to manage the interaction between these stable and changing system elements

In the software domain, patterns isolate expected invariant system elements from the effects of change to system hot spots

6. A pattern is part of a language Every pattern is connected to and shaped

by other patterns

Patterns are part of a network of interrelated patterns: a pattern language

When patterns are combined they form a language for describing design solutions

Pattern quotes … “No pattern is an isolated entity. Each pattern can exist

in the world, only to the extent that it is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it.”*

“This is a fundamental view of the world. It says that when you build a thing you cannot merely build that thing in isolation, but must also repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole.”*

* C. Alexander, S. Ishikawa, and M. Silverstein, A Pattern Language, Oxford Univ. Press, New York, 1977.

Pattern Languages Pattern languages are critical because they

capture the emergent behavior of complex systems

A pattern language is therefore a collective of solutions to reoccurring problems

A good pattern language guides a designer towards a good system architecture

The whole is more than that sum of the parts: a pattern language is more than the sum of its patterns

7. A pattern is validated by use Patterns are usually discovered

through concrete experience rather than abstract argument

A pattern cannot be verified or validated from a purely theoretical framework

A pattern is validated by use In spoken language new words are devised and

old words acquire new meanings through repeated use

Words can also be theoretically devise, although not validated until it achieves widespread use

Likewise, a pattern’s repeated presence in existing artifacts confirms it usefulness

Programming theory is important but to be meaningful it must be evaluated in a concrete environment

A pattern is validated by use Patterns are validated by

experience rather than by testing

Validating pattern existence by experience is difficult because it is hard to know when a patterns is complete and correct

8. A pattern is grounded in a domain A pattern is not an isolated entity

Patterns are defined in the context of other patterns and with respect to a particular field to which it applies

A pattern is grounded in a domain Discussion of a pattern only makes

sense as part of a pattern language

A discussion of patterns must clarify what domain the patterns serve and it must ensure that all the patterns share a common domain

9. A pattern captures a big idea Design patterns are not solutions to

trivial problems Not every design problem warrants a

pattern

Patterns focus on difficult problems in a particular area Problems designers face in a certain area

time and time again

A pattern captures a big idea Therefore, a pattern language captures

a domain. The patterns in the language identify the

domain’s key concepts and their interplay

A pattern must strike a balance between a solution to a specific problem and if that problem is significant enough to warrant a pattern

Conclusion Developing a definition that completely

captures the pattern concept is neither worthwhile nor possible

What is possible and worthwhile is to document essential characteristics Clarifies and develops our understanding of

patterns Therefore increasing our ability to identify them

Questions ???