Design Patterns Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich [email protected] 2 outline . past . patterns in action . patterns today . next 3 a fifteen year old thought experiment imagine that you are struggling with a • you have spent days on the problem difficult software design • there was no obvious answer problem …in frustration and desperation you reach up to your bookshelf or google .... • presents design problems, issues, and solutions in a commonly ... and find the answer in understood and shared language The Software • captures experience and expertise of designers Architecture Handbook • provides a common and agreed position of what constitutes good and bad design unfortunately the handbook does not exist but raises some • what should such a handbook contain and not contain? interesting questions • Who would use it? How would they use it? about what it might look • how could readers can best absorb the content and put into it into like practice? See also http://www.handbookofsoftwarearchitecture.com created by Grady Booch 4 towards the goal ? • http:// www.handbookofsoftwarearchitecture.co m initiated by Grady Booch The Handbook of Software Architecture is a concise reference on the design of software-intensive systems. Written for software architects, developers, and project managers, the Handbook presents the fundamentals of software architecture, covering contemporary best practices for specifying, visualizing, documenting, governing, and evolving a system's significant design decisions. The center of this work presents the as-built architecture of a variety of software- intensive systems selected from across the industry and from across the world. 5 clues from other disciplines mechanical engineering furniture and timber architecture handbooks framing handbooks “I have drawn up definite rules to “Mechanisms of Modern "If you combine technique and enable you to have personal Engineering Design”: Ivan knowledge of the material, will knowledge of the quality both of Artobolevsky 1947 automatically design around the existing buildings and of those construction, and not construct which are yet to be constructed." around the design. ... as ... construction becomes second "A temple is called IN ANTIS, nature when you are designing." when it has antæ or pilasters in front of the walls which Tage Frid enclose ..." Marcus Vitruvius Pollio “De Architectura Libri Decem" 27 BC 6 capturing and describing good design describe • captures commonly occurring solutions to commonly problems that occur again and again recurring designs • helps avoid design déjà vu • provides guidelines when to use and when not grounded in real practice • captures “why” decisions, design alternatives, rationale • provides design alternatives and describes not just descriptive relative merits and trade-offs • provides implementation hints extracts essence of design • provides freedom to adapt to particular context A Pattern is a way to capture recurring designs in such a way that Design Patterns others can readily acquire and use the knowledge and experience 7 a design patterns inspiration . The iPhone SDK is based on the NeXTStep object-oriented frameworks . Existed before we wrote Design Patterns 15 years ago . Source of inspiration for several design pattern variations for: Adapter, Bridge, Proxy, Observer and Chain of Responsibility good design survives 8 early steps - recurring patterns in object- oriented designs Initial Focus on Object Oriented Design First dozen of patterns reverse architected from ET++ (91) Jim Coplien’s catalog of C++ idioms (91) John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma get together between (90-92) to write Design Patterns • Smalltalk, C++ focus • first version of catalog • 23 pages long • only experts understand it: • “oh, I’ve done that” • Inspirations from Smalltalk, InterViews, NeXTStep, ET++ Design Patterns published October 1994 9 eclipse . introduced . pattern variations . XML based configuration . extension points, lazy loading . API focus . evolution patterns 10 eclipse pattern variations . XML based configuration for extending the system plugin.xml <action toolbarPath=“search" icon="icons/opentype.gif“ toolTip=“Open Type” class="org.eclipse.jdt.OpenTypeAction"/> lazily instantiated using reflection org/eclipse/jdt/OpenTypeAction.class contribution implementation 11 APIs first . APIs don’t just happen; we need to design them . specifications with precisely defined behavior . what you can assume (and what you cannot) . it works ≠ API compliant . documented classes ≠ API . must have at least one client involved, preferably more 12 API evolution patterns . compatibility layer . I*2 extensions interfaces public interface IActionDelegate { … } // original interface public interface IActionDelegate2 extends IActionDelegate { void dispose(); } if (d instanceof IActionDelegate2) { IActionDelegate2 d2 = (IActionDelegate2) d; d2.dispose(); // call new method } . extension object pattern: IAdaptable 13 Extension Object Pattern: IAdaptable . adding interfaces to existing types . Interface negotiation <extension point="org.eclipse.core.runtime.adapters"> <factory class="org.eclipse.jdt.internal.ui.JavaElementAdapterFactory" adaptableType="org.eclipse.jdt.core.IJavaElement"> <adapter type="org.eclipse.ui.IPersistableElement"/> … </factory> 14 JUnit . A simple framework . Design pattern dense . Simplified using annotation/attribute based programming 15 JUnit3 ⇒ JUnit4 Test Composite:Component run(TestResult) . thinned framework for the client (inspiration from NUnit) Command TestCase TestSuite Composite Template Method run(TestResult) run(TestResult) “replaced” inheritance with fTests runTest() addTest(Test) setUp() annotations TestResult tearDown() Composite: Leaf Collecting Parameter fName Pluggable Adapter MoneyTest MoneyTest Command @Before setUp() setUp() @Test simpleAdd() testSimpleAdd() @Test mixedAdd() testMixedAdd() JUnit3 JUnit4 outline . past . patterns in action . patterns today . next 17 scope of patterns has broadened 70's 80's 90's 2000's Today Topics Buildings & Architecture Requirements Analysis OOPSL ECOOP Software Design A BOF Architecture System Design Programming Conferences J2EE, .NET Organisation Real-time, Embedded Project Management, Organisation Source: Amazon,com, Hillside.net 16 years of growth 18 patterns today - useful, used, useable . useful - patterns enable to repeat a successful design done by someone else . between 'if-then-else" and layering, decoupling . a good pattern is convincing . non-obvious solution ⇒ surprise its users, experts “I’ve done that” . used - recurring phenomenon . used in discussions, in code and documentation to talk about design . APIs and libraries . usable major. include contribution coding is communication details, support of commonly many variations occurring design problems and solutions 19 patterns community . the active pattern community was and is a key element to the success of patterns . the pattern community has its own culture . writer’s workshop . shepherding work . published as “Pattern Languages of Program Design” . 9 regular conferences on 5 continents . ChiliPLoP, EuroPLoP, VikingPLoP, KoalaPLoP, SugarLoaf PLoP,… . 5 volumes of “pattern languages of program design” ⇒ patterns continue to flourish ⇒ new leaders are emerging 20 patterns & design . refactor to patterns . patterns not measure of goodness . some patterns are cool, but this doesn't make them more relevant . patterns used for . variability management . decoupling . dependency management patterns a means to an end, not the end 21 patterns & complexity . each pattern makes a system a little bit more complex . software infrastructures are getting more and more complex… . using lots of unnecessary patterns makes a system so complex that it becomes unmanageable this isn't the patterns fault… but … we have never discussed when to remove a pattern from a system 22 dangerous patterns . Mediator . supposed to be used to allow colleagues to be reusable . is often used to allow programmers to continue to be procedural. Singleton . supposed to be used to encapsulate global state when it cannot be eliminated . is often used as a justification of global state adding global state is easy – removing it hard! 23 what the students are saying about patterns . “we had them all…” . Erich Gamma is considered the enemy by many CS students . patterns are supposed to solve real software engineering problems (or something; what do I know?) . I spent most of the time trying to figure out what "Chocolate Factory" and various bizarre chocolate eating habits that border on obsessive-compulsive disorder had to do with the Abstract Factory and Singleton design patterns have we solved how to teach patterns? 24 feedback: “voting off the island” . OOPSLA workshop 2004*: people voted on the patterns to indicate which ones they felt needed deletion in the current form . four patterns were voted off . Factory Method – confusion with Factory . Bridge . Flyweight . Interpreter . reason: people felt they were sufficiently uncommon . split decisions . Singleton . Chain of Responsibility * http://martinfowler.com/bliki/OOPSLA2004.html 25 feedback “while the book is still essential reading for anyone in the OO space, there's much that could be done to modernize it” -- Martin Fowler “there is more to both OO design and patterns than is achieved or intended by the Gang of Four” -- Frank Buschmann, Kevlin Henney “Beyond the Gang of Four” I totally agree!! 26 outline . past . patterns