Design Patterns

Motivation/Background (1) Developing software is hard Developing reusable software is even harder Why not leverage proven solutions to common problems? Two ways to do this: Design Patterns Support reuse of class-level design Capture static and dynamic structures and collaborations of successful solutions Frameworks Support reuse of detailed design and code Integrated set of components that provide partial solutions to problems

Motivation/Background (2) How do you become a software design master? Learn the foundations Algorithms, data structures, programming languages Learn the principles of good design Abstraction, encapsulation, and modularity Study the designs of masters Understand, memorize, mimic Practice Hands-on experience, multiple situations

Intro to Design Patterns Represent sound solutions to common problems that arise with particular contexts Particularly useful at resolving nonfunctional forces Ease of modification Ease of reuse Ease of extension A good design is revealed when you attempt to change it

An Example: The Observer Design Pattern (1) Sample application: stock quote service Intent: define one-to-many dependency between objects so that when one object changes state, all its dependent objects are notified

An Example: The Observer Design Pattern (2) Key Forces: There may be many observers Each observer may react differently to same notification The observable should be decoupled from the observers to allow them to change independently Observers should be able to query observable for required information

An Example: The Observer Design Pattern (3) Structure of the Design Pattern: Not really necessary

An Example: The Observer Design Pattern (4) Collaboration of the Design Pattern: Not needed

Canonical Design Pattern Description Name Intent Forces Non-Software Example Abstract Description Implementation Issues Consequences Java API Usage Responsibility-Driven Post-Mortem Example

Frameworks vs. Patterns (1) Important to understand the relationship between these two ways to reuse designs Frameworks (1) Semi-complete applications Can be tailored to specific applications Inheritance Template Instantiation Callbacks Frameworks provide domain-specific functionality Ex: Backtracking framework

Frameworks vs. Patterns (2) Frameworks exhibit inversion of control Framework acts on domain classes Framework pulls domain objects into process Typically through hooks or callbacks Benefits of Frameworks Enable direct reuse of code Enable reuse of overall design Drawbacks of Frameworks High initial learning curve Many classes, interfaces, levels of abstraction Flow of control is non-intuitive Pull versus push model Hard to see how domain code fits

Frameworks vs. Patterns (3) Several different types of software patterns Architectural Design Idioms Architectural Patterns Expose fundamental structural organization of system or subsystem Provide decomposition into subsystems Provide “big picture” of system High-level Abstraction Example: Blackboard Architecture

Frameworks vs. Patterns (4) Design Patterns Provide scheme for refining components Freeze commonly-reoccurring structure Middle-level Abstraction Example: Observer/Observable Notice how this could be used to implement a blackboard architecture Idioms Describe how to implement a particular aspect of a component in some language Low-level Abstraction Example: Reference Counts

Structure of Design Patterns (1) Divided by purpose and scope (1) Scope Does it apply to classes or objects? Class Patterns deal with relationships between classes Static – compile-time relationships Frequently involve inheritance Not the typical design pattern Object Patterns deal with relationships between objects Dynamic – change at run-time Frequently involve aggregation/delegation

Structure of Design Patterns (2) Divided by purpose and scope (2) Purpose What the pattern does Three categories Structural Patterns Creational Patterns Behavioral Patterns Deal with decoupling interface and implementation Set the system up for modification Examples: Adapter – translate one interface to another Composite – recursive aggregation

Structure of Design Patterns (3) Divided by purpose and scope (3) Creational Patterns Initialization and configuration Examples Singleton – controlled instance count Factory Method – use inheritance to create instances of abstract classes Behavioral Patterns Dynamic interactions among objects/classes Examples: Iterator – give sequential access to collection Template Method – separate variant and invariant aspects of process

Structure of Design Patterns (4) What makes a pattern a “pattern”? (1) Describe a problem A problem that arises frequently Explains forces at work Ex: Aspects that must be changed frequently Present a solution Proven solution to the problem Must indicate how it balances the active forces Must define both static and dynamic aspects of solution

Structure of Design Patterns (5) What makes a pattern a “pattern”? (2) Have a context Must indicate when/where the solution can be used Describes the situation in which the problem arises Recur Must be relevant to more than one situation Teach Must provide sufficient understanding to allow it to be tailored Name

Key Principles of Design Patterns Separate interface from implementation Program to the interface, not the implementation Separate variant from invariant aspects Define what is likely or desirable to change Build in flexibility for variant aspects Prefer aggregation/delegation/composition over inheritance Use aggregation to extend existing code Creates “black box” reuse Inheritance is for defining abstract hierarchies Open/Closed Principle Open to extension, closed to modification Easy to extend and does not require modification to do so

Key Benefits of Design Patterns Large-scale reuse of class architecture Above the single class level Capture expert knowledge/tradeoffs Improve developer communication Own vocabulary Encourage documentation/review

Design Pattern Books “Design Patterns”, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Excellent reference Not generally considered a good textbook Examples in C++ “Head First Design Patterns” by Eric Freeman and Elisabeth Freeman Better as a textbook Weaker as a reference Examples in Java Others…

Key Drawbacks of Design Patterns No direct code reuse Language-independent Must be recoded each time Deceptively simple Leads to misuse Overload Can be too many patterns to find what you want Validated only through experience/discussion No formal testing of design patterns Refactoring development process takes time Several attempts to understand how/when to use

Anti-Patterns Introduced by William Brown Tells what to avoid Classic book by same name Another good book - “Bitter Java”, by Bruce Tate Tells what to avoid Key is that it looks great but will fail An anti-pattern is A pattern that tells: how to go from a problem to a bad solution how to go from a bad solution to a good solution Simple Examples: Using primitive arrays rather than array objects Cut-and-paste programming – “one rule one place”