1. Introduction to Design Patterns (1)

2. Definition: “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.” wikipedia: software pattern yes but..nobut..yes but…

3. So what are “patterns” really? Trendy: Recent "hot-topic", OOD buzzword, lots of "hype” Literary: Form of software engineering problem-solving documentation Pragmatic: Describe practical solutions to "real world" problems Recurring: Identify good design structures which recur in practice Generative: Show how/when to apply the solution, and generate the desired design structure Emergent: Larger solutions emerge indirectly from applying patterns in succession, and in concert together (Brad Appleton)

4. Origins & history • “patterns” idea originated in the work of architect Christopher Alexander in books such as the Notes on the Synthesis of Form (1964) and A Pattern Language, with Ishikawa and Silverstein (1977). • Alexander’s early ideas were taken up by software engineers (1960’s and 70’s) and influenced programming theory, programming language design, modular programming and software engineering. • In the late 1980's the idea of “patterns” was adopted by the object oriented software community. Authors such as Ward Cunningham and Kent Beck applied patterns in the design of Smalltalk windows. • In the 1990’s the power of “patterns” became widely recognized and patterns became part of the mainstream with the “gang of 4” (GoF) book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson & Vlissides. • Since then, the “patterns” idea has spread and work has also been done in the areas of analysis patterns, process patterns, organizational patterns and others.

5. Why do we need Patterns? • Reusing design knowledge • Problems are not always unique. Reusing existing experience might be useful. • Patterns give us hints to “where to look for problems and possible solutions”. - Establish common terminology (shared vocabulary) • Easier to say, “We need a observer here”. - Provide a higher level perspective • Frees us from dealing with the details too early - In short, it’s a “reference”

6. Pattern ‘types’: - Design Patterns (software design; often object-oriented): • architecture (systems context & design) • design (component interactions) • programming idioms (language-specific techniques/style) - Analysis Patterns (recurring & reusable analysis models) - Organization Patterns (structure of organizations/projects) - Process Patterns (software process design) - Domain-specific - e.g. user interface, web design, secure usabilty or any other domain you can think of!

7. Pattern elements or description • Name • A meaningful "conceptual handle" for discussion - Context • Tells how the problem occurs / when the solution works - Problem • Statement of the problem / intent of the solution • Forces • Trade-offs, goals+constraints, motivating factors/concerns • Tells why the problem is difficult - Solution • Tells how to generate the solution • The solution structure, its participants & collaborations • Examples (optional) • showing real uses of the pattern

8. Pattern elements or description (cont.) - Resulting Context Describes the end result, benefits and consequences Shows how the forces were balanced/traded-off Tells how the solution works out - Rationale (optional) Underlying principles/heuristics justifying the solution Tells underpinnings of why the solution works out - Related Patterns Patterns which are similar, or which may precede/follow this one - Known Uses 3 or more independent instances of "real world" success

9. Software architecture patterns (next week): • Layers • Model-View-Controller, Presentation-abstraction-control, Model View Presenter and Model view viewmodel • Multitier architecture (often three-tier) • Pipeline • Implicit invocation • Blackboard system • Peer-to-peer • Service-oriented architecture • Naked objects

10. the other side of the coin ..or anti-patterns • patterns are positive (yang) - they tell us how we might go about doing something and what has proved useful in the past … • anti-patterns are negative (yin) – they tell us about possible pitfalls and what to avoid…

11. anti-patterns • “In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.” • Wikipedia currently lists known anti-patterns under the following headings (needs to be read critically as many simply idioms) • 1.1 Organizational anti-patterns • 1.2 Project management anti-patterns • 1.3 Analysis anti-patterns • 1.4 Software design anti-patterns • 1.4.1 Object-oriented design anti-patterns • 1.5 Programming anti-patterns • 1.6 Methodological anti-patterns • 1.7 Configuration management anti-patterns