Introduction to Design Patterns The history of patterns Architecture and Software

© Henrik Bærbak Christensen2 What is a valve? En vandhane er egentlig en ventil af den type, som benævnes en sædeventil. Figuren viser hvilke foranstaltninger man tager for at gøre den tæt. (a) er det i ventilhuset fastsiddende sæde, (b) en flad eller konisk pakning. (c) og (d) pakninger mellem spindel og ventilhus (A) Skitsen viser en sædeventil med åbning for væskepassage (1) og ventilkegle (2), der undertiden er plan som her vist. (B) er en dobbelt sædeventil, hvor en vis kompensation i sædebevægelsen kan opnås. (C) viser en Butterfly-ventil med et drejeligt spjæld, der ved åben ventil står parallel med strømningsretningen. På (D) ses en kuglehane med kugleformet told hvorigennem væsken strømmer.

© Henrik Bærbak Christensen3 Or a pump? 1. Sugepumpe med stempel (a). Ventilerne b og c åbner og lukker sig, efter som stemplet føres op eller ned. Når stemplet hæves, fortyndes luften under det, og vandet suges op i sugerøret. 2. Sugepumpe med dykkerstempel (a) og vindkedel (b). Vindkedelen forhindrer, at vandstrålen strømmer ud stødvis; luften i vindkedelen bliver sammenpresset og trykker bagefter vandet ud som en jævn strøm. 3. Tandhjulspumper anvendes mest som oliepumper. 4. Centrifugalpumpen er en strømningsmaskine, hvori et motordrevet, roterende skovlhjul (a) tilfører bevægelsesenergi til væsken, der tilledes aksialt og slynges udefter af centrifugalkraften. I et spiralformet pumpehus (b) omsættes bevægelsesenergien til tryk.

© Henrik Bærbak Christensen4 Architectural Patterns Christopher Alexander –Notes on the Synthesis of Form (1964) –The Oregon Experiment (1975) –A Pattern Language: Towns, Buildings, Constructions (1977) –The Timeless Way of Building (1979) 253 patterns for regions, cities, towns, neighborhoods, transport, home, offices, worksites, rooms, lightening, windows, gardens, waiting rooms, wall,... A quality without a name

© Henrik Bærbak Christensen5 Christopher Alexander Each pattern describes a problem which occurs over and over again in our envi- ronment, and then descri- bes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander worked on planning towns and buildings, but the definition works just as well for object-oriented patterns. In software the solution is expressed in terms of objects, roles, interfaces, and collaboration patterns instead of windows, doors and walls, but the contents of a patter is always: A solution to a problem in a context

© Henrik Bærbak Christensen6 ‘Alcoves’: One of Alexander’s patterns 179. Alcoves **... many large rooms are not complete unless they have smaller rooms and alcoves opening off them.  No homogeneous room, or homogeneous height, can serve a group of people well. To give a group a chance to be together, as a group, a room must also give them the chance to be alone, in one’s and two’s in the same space. This problem is felt most acutely in the common rooms of a house – the kitchen, the family room, the living room. In fact it is so critical there, that the house can drivee the family apart when it remains unsolved... In modern life, the main function of a family is emotional; it is a source of security and love. But these qualities will only come into existence if the members of the house are physically able to be together as a family. This is often difficult. The various members of the family come and go at different times of day; even when they are in the house, each has his own private interests... To solve the problem, there must be some way in which the members of the family can be together, even when they are doing different things. Therefore: Make small places at the edge of any room, usually no more than 6 feet wide and 3 to 6 feet deep and possibly much smaller. These alcoves should be large enough for two people to sit, chat, or play and sometimes large enougf to contain a desk or table.  Give the alcove a ceiling which is markedly lower than the ceiling height in the main room... (Alexander, 1977)

© Henrik Bærbak Christensen7 From architecture to software OOPSLA Ward Cunningham & Kent Beck: Using Pattern Languages for Object-Oriented Programs (1987) Bruce Andersen, GoF, Jim Coplien, Doug Lea, Desmond D’Souza, Norm Kerth, Wolfgang Pree (Workshops, ) The Hillside Group (Colorado, August 1993, April 1994) Kent Beck and Grady Booch,..., PLoP GoF: Design Patterns (1994)... and the ball got rolling...

Contents of a pattern

© Henrik Bærbak Christensen9 A Pattern is really just a writing template – a particular style of literature Name Problem Solution Consequences

© Henrik Bærbak Christensen10 Name A name is a handle that allows us in a simple word or two to describe the whole idea: a design problem, its solution and consequences of using it. Naming a pattern augments our vocabulary and allow us to design at a higher level of abstraction Naming allows communication: discussing the appropriateness of some design solution with colleagues as well as referring to it in documents. NameProblemSolutionConsequences

© Henrik Bærbak Christensen11 Problem The problem describes situations where the pattern may be used, and describes the problem in its context. Often there are some conditions that must be fulfilled before the pattern is relevant. GoF crystallized the problem in a single or two short sentences denoted the pattern’s intent NameProblemSolutionConsequences

© Henrik Bærbak Christensen12 Solution The solution describes the elements in the design, their relations and collaboration patterns. Usually described using UML, pseudo code, prose... It does not describe a specific, concrete design or implementation but rather how certain roles are structured and/or interact with each other. Thus the solution is general. A pattern is a template that may be applied in many different situations. “... you can use this solution a million times over, without ever doing it the same way twice.” NameProblemSolutionConsequences

© Henrik Bærbak Christensen13 Consequences Consequences describes the result of using a pattern: benefits and liabilities. These are very important to consider when evaluating design alternatives. That a pattern can be applied is not necessarily the same as it should! Applying any patterns will almost always influence the architecture’s quality attributes: Performance, usability, modifiability, cost, roll- out-schedule, etc. NameProblemSolutionConsequences

© Henrik Bærbak Christensen14 Example: Strategy from RFSE More elements are usually present, but the basic four literary elements are present.

© Henrik Bærbak Christensen15 Two Definitions Software view: “what it is + why” Prose view: “how it is captured”

© Henrik Bærbak Christensen16 Example: Dating Patterns Fifth Position Break –You want to easily find women and create sessions by exposing desirable services and attributes. Pan-Dimensional Renaissance Differentiator –You want women to admire and notice you Jini Singles Bar –You want to create stateful session with a designated peer but you don’t know the name or address for suitable contenders of peer-to-peer networking Half Bad Boy Plus Protocol –You want to compete with dangerous, nonsecure Bad Boy implementations whose services are viewed as more desirable.

© Henrik Bærbak Christensen17 Summary Patterns are (name, problem, solution, consequence) writing templates. Provides –language –best practices