Patterns Design II Alexei Khorev
Design Patterns II
Gang of Four Pattern Catalog Erich Gamma on Design Patterns COMP2110/2510 Software Design Software Design for SE September 10, 2008
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
Alexei Khorev Department of Computer Science The Australian National University
16.1
Design Patterns II Alexei Khorev
1 Software DPs
Software DPs The Design Pattern Bible JUnit case study
2 The Design Pattern Bible
GoF Catalog
3 JUnit case study
4 GoF Catalog
16.2
Refresh DPs denition
Design Patterns II Alexei Khorev
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
According to Buschmann et al, PatternOriented Software Architecture, Wiley 1996:
A pattern for software architecture describes a particular recurring design problem that arises in specic design contexts and presents a well-proven generic scheme for its solution. The solution scheme is specied by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.
16.3
What the Design pattern is?
Design Patterns II Alexei Khorev
A design pattern is a way of reusing abstract knowledge
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
about a problem and its solution
A pattern is a description of the problem and the essence of
its solution
A pattern is a reusable abstraction which can be applied in
different settings
A pattern is the abstraction from a concrete form which keeps
recurring in specic non-arbitrary contexts
Pattern is an abstraction which goes beyond object
characteristics such as inheritance and polymorphism, and often relies on them
16.4
What the Design pattern does?
Design Patterns II Alexei Khorev
A design pattern represents a widely accepted solution to a
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
recurring design problem in OOP
A design pattern describes how to structure classes to meet a
given requirement
A design pattern provides a general blueprint to follow when
implementing part of a program
A design pattern does not describe how to structure the entire
application
A design pattern does not describe specic algorithms A design pattern focuses on relationships between classes
16.5
Design patterns characteristics
Design Patterns II Alexei Khorev
A pattern describes a solution to a recurring problem that arises in specic design situations Patterns are not invented; they are distilled from practical experience Patterns describe a group of components (eg, classes or objects), how the components interact, and the responsibilities of each component. That is, they are higher level abstractions than classes or objects Patterns provide a vocabulary for communication among designers. The choice of a name for a pattern is very important Patterns help document the architectural vision of a design. If the vision is clearly understood, it will less likely be violated when the system is modied Patterns provide a conceptual skeleton for a solution to a design problem and, hence, encourage the construction of software with well-dened properties Patterns are building blocks for the construction of more complex designs
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
Patterns help designers manage the complexity of the software. When a recurring pattern is identied, the corresponding general solution can be implemented productively to provide a reliable software system.
16.6
The Gang-Of-Four Book
Design Patterns II Alexei Khorev
The adoption and efcient use of a new technology benets greatly from a systematic and high quality description of such technology. In the case of DPs, the incontestable source of their description is the famous book:
Author Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Title Design Patterns: Elements of Reusable Object-Oriented Software Publisher AddisonWesley Year 1995
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
16.7
Facts about the GoF book
Design Patterns II Alexei Khorev
The authors worked on it over four years, selecting OO
design practices which could be recast as design patterns, distilling the presentation, culling those deemed not immature yet etc. The result:
One of the top bestselling books on software fourteen
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
years on, its reprinted 3-4 times a year, more than half a million copies have been sold so far. People are eagerly waiting for a new edition. . .
Printed T-shirts with individual DPs can be
purchased from Coder Gear Company choose your favourite design pattern today! A CD version of the book is also available (very handy!) Now, Amazon does not only sell the book, but also provide an on-line copy for reading (akin to Google Books service)
16.8
Erich Gamma on GoF experience Erich Gamma gave a series of interview to Aritma Developer on-line magazine in which he offered a valuable advice on the practice of design pattern. Here are some quotes:
Design Patterns II Alexei Khorev
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
You have to feel the pain of a design which has some problem. [Only then] you. . . appreciate a pattern. Like realizing your design isnt exible enough, a single change ripples through the entire system, you have to duplicate code, or the code is just getting more and complex. If you then apply a pattern in such a messy situation it can happen that the pain goes away and you feel good afterwards. Its an eye opener to realize that oh, actually this pattern, factory or strategy, is a solution to my problem. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. (20 out 23 case) These days software is too complex. We cant afford to speculate what else it should do. We need to really focus on what it needs. Thats why I like refactoring to patterns.
16.9
Pattern-driven design: JUnit framework The famous testing framework JUnit was rst developed by Kent Beck and E. Gamma during a trans-atlantic ight in 1997. The circumstances of this feat (Never software industry owed so much to so fewer lines of code) is the testimony of the great communicative benets which DPs bring into software development:
Design Patterns II Alexei Khorev
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
Kent and I were uent in patterns when we designed JUnit. So of course, wed say things like, "Hey, thats composite." Composite is a pattern in JUnit. We also use template method. Thats a basic one. We have command. This is of course a key one. We started with test and said, "Oh, this is a command. Oh, this is a template." Because we were uent in patterns, our conversation was going really fast, enabling a high-velocity design. [The high-velocity design means
just that over six-seven hours at the high altitude.] On the difference with Alexanders pattern approach language to design:
. . . when you follow Alexanders patterns approach you follow the patterns in some sequence. We dont prescribe a particular order. If you have a problem, we have the solution for that, but we dont have the next step. We dont give you hints on what to do next. Alexander is way more thorough in this regard.
16.10
Design of JUnit Goals of JUnit (mission statement):
Create facility for automated tests for classes developers write
Design Patterns II Alexei Khorev
Software DPs
It has to be a small (easy to learn) framework (exible and
adoptable)
Make created tests to retain their value over time; allow to
The Design Pattern Bible JUnit case study GoF Catalog
combine tests and run them independently
Leverage existing tests to create new ones provide setup
or xtures for automated selection of tests for run and creating an appropriate execution environment Design approach: 1 start with nothing (skip the SRS, ) 2 apply patterns, one after another, until you have the architecture of the system 3 Rene and refactor the design
16.11
JUnit Design TestCase, Command The core of the JUnit testing technique is an object of the TestCase class. Standard testing techniques:
Design Patterns II Alexei Khorev
Software DPs
print statements debugger expressions test scripts
The Design Pattern Bible JUnit case study GoF Catalog
To make manipulating tests easy, one has to make them objects. The test object has to execute a testing routine. The Command pattern deals with creating object for an operation and give it a method execute this intent ts the goal perfectly.
public abstract class TestCase implements Test { private final String fName; public TestCase(String name) { fName = name; } public abstract void run() ... }
16.12
JUnit Design run(), Template Next, one has to dene the place to put the xture code and the test code itself. The common structure to all tests they set up a test xture, run some code against the xture, check some results, and then clean up the xture. Template Method intent addresses the problem: Dene the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redene certain steps of an algorithm without changing the algorithms structure.
The developer should to be able to separately consider how to write the xture (set up and tear down) code and how to write the testing code. The execution of this sequence, however, will remain the same for all tests, no matter how the xture code is written or how the testing code is written.
Design Patterns II Alexei Khorev
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
public void run() { setUp(); runTest(); tearDown(); }
16.13
JUnit Design TestResults After the test has run, one has to get a summary of what did and didnt work. Because tests are expected to work, we only want to record the failures and a highly condensed summary of the successes. The Smalltalk pattern (but not GoF!), Collecting Parameter, ts the bill: when you need to collect results over several methods, you should add a parameter to the method and pass an object that will collect the results for you. We create a new object, TestResult, to collect the results of running tests.
public class TestResult { protected int fRunTests; ublic TestResult() { fRunTests= 0; } } public void run(TestResult res) { res.startTest(this); setUp(); runTest(); tearDown(); }
Design Patterns II Alexei Khorev
Software DPs The Design Pattern Bible JUnit case study GoF Catalog
For details see JUnit A Cooks Tour.
16.14
JUnit Design TestCase, Adapter
We need an interface to generically run our tests, but all test cases are implemented as different methods in the same class. This avoids the unnecessary proliferation of classes. A given test case class may implement many different methods, each dening a single test case. Each test case has a descriptive name like testMethod1() etc. The test cases dont conform to a simple command interface. Different instances of the same Command class need to be invoked with different methods. Therefore our next problem is make all the test cases look the same from the point of view of the invoker of the test...