1. Introduction to Design Patterns (1)

2. “ 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..no but..yes but Definition:

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).Notes on the Synthesis of FormA Pattern Language -Alexander’s early ideas were taken up 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.Design Patterns: Elements of Reusable Object- Oriented Software -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 oProblems are not always unique. Reusing existing experience might be useful. oPatterns give us hints to “where to look for problems and possible solutions”. -Establish common terminology (shared vocabulary) oEasier to say, “We need a observer here”. -Provide a higher level perspective oFrees us from dealing with the details too early - In short, it’s a “reference”

6. Pattern ‘types’: - Design Patterns (software design; often object-oriented): oarchitecture (systems context & design)architecture odesign (component interactions) oprogramming 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 oA meaningful "conceptual handle" for discussion - Context oTells how the problem occurs / when the solution works - Problem oStatement of the problem / intent of the solution -Forces oTrade-offs, goals+constraints, motivating factors/concerns oTells why the problem is difficult - Solution oTells how to generate the solution oThe solution structure, its participants & collaborations -Examples (optional) oshowing 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. 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