Introduction to Patterns and Many problems recur. Design Patterns - PDF document

Observations  Engineering=Problem Solving Introduction to Patterns and  Many problems recur. Design Patterns  Many problems have the same (or at least similar) solution structure.  Exact solution is dependent on the context  A more experienced person can solve new Eunjee Song problems faster and better. Dept. of Computer Science  Fundamental to any engineering discipline (even Baylor University any science): a common vocabulary for expressing its concepts, and a language for relating them together. Some slides adapted from slides by R. France and B. Tekinerdogan Eunjee Song Deign Patterns Intro-1 Eunjee Song Deign Patterns Intro-2 Electrical Engineering Patterns Mechanical Engineering Patterns Eunjee Song Eunjee Song Deign Patterns Intro-3 Deign Patterns Intro-4 Chemical Engineering Patterns Software Engineering Patterns Eunjee Song Eunjee Song Deign Patterns Intro-5 Deign Patterns Intro-6 1

Origin of the term "pattern” Pattern: Problem-Solution-Context  Timeless Way of Building (Oxford University Press, 1970) Work on software development patterns stemmed from work on patterns from building architecture carried out by Christopher Alexander . Eunjee Song Deign Patterns Intro-7 Eunjee Song Deign Patterns Intro-8 Patterns Solve What are software patterns? Software Structural Problems like...  Abstraction,  Patterns are intended to capture the best available software development experiences in  Encapsulation the form of problem-solution pairs.  Information hiding  A pattern outlines solutions to a family of  Separation of concerns  Separation of concerns software development problems in a particular software development problems in a particular context.  Coupling and cohesion  A pattern outlines a process for transforming  Separation of interface and problems targeted by the problem to solutions implementation characterized by the pattern.  Single point of reference  Divide and conquer Eunjee Song Eunjee Song Deign Patterns Intro-9 Deign Patterns Intro-10 Patterns Solve Pattern Types Non-functional Problems like... Requirements Patterns : Characterize families of  requirements for a family of applications  e.g., checkin-checkout pattern: can be used to obtain requirements for library systems, car rental systems, video  Changeability systems, etc.  Interoperability Architectural Patterns : Characterize families of  architectures  Efficiency  e.g., Broker pattern: can be used to create distributed systems in which location of resources and services is systems in which location of resources and services is transparent (e.g., the WWW)  Reliability  Other examples: MVC, Pipe-and-Filter, Multi-Tiered  Testability Design Patterns : Characterize families of low-level design  solutions  Reusability  Examples: Gang of Four (GoF) patterns Programming idioms : Characterize programming language  specific solutions Eunjee Song Eunjee Song Deign Patterns Intro-11 Deign Patterns Intro-12 2

Example of an Architectural Pattern - MVC Solution Outline: Split Application Model-View-Controller (MVC) Pattern into 3 Areas:  Context : Developing user-interfaces (UIs )  The Model component: encapsulates core functionality; independent of input/output  Problem : How to create a UI that ’ s resilient to representations and behavior. changes such as changes in look-and-feel  The View components: displays data from the windowing system, changes in functionality. model component; there can be multiple views d l t th b lti l i  Factors : changes to UI should be easy and possible for a single model component. at run-time; adapting or porting the UI should not  The Controller components: each view is impact the implementation of the core functionality. associated with a controller that handles inputs; the user interacts with the system via the controller components. Eunjee Song Deign Patterns Intro-13 Eunjee Song Deign Patterns Intro-14 Patterns Summary Patterns, Architectures & Frameworks  A pattern addresses a recurring software development problem that arises in a particular  There can be confusion between patterns, context, and outlines a solution for it. architectures and frameworks.  A pattern captures ‘ best practices ’ in software  Architectures model software structure at development (the intention! ). the highest possible level, and give the  A pattern should be based on actual experiences in overall system view. An architecture can use industry  Patterns provide a common vocabulary for, and many different patterns in different understanding of ‘ best practices ’ . components  Developers can refer to a pattern by name (e.g., the Adapter pattern) and others familiar with the pattern will not need further description Eunjee Song Eunjee Song Deign Patterns Intro-15 Deign Patterns Intro-16 Patterns, Architectures & Frameworks Summary of Differences (cont...)  Patterns are more general and abstract than frameworks. A pattern is a description of a  Patterns are more like small-scale or local problem-solution pair , not a solution (or problem) architectures for architectural components itself. or sub-components  A pattern cannot be directly implemented. An  Frameworks are partially completed implementation is an example of a pattern. software systems that may be targeted at  Patterns are more primitive than frameworks. A a particular type of application. These are framework can employ several patterns. tailored by completing the unfinished components. Eunjee Song Eunjee Song Deign Patterns Intro-17 Deign Patterns Intro-18 3

Gang of 4 (GoF) Design Pattern Scope Criterion Classification Scope determines whether a pattern applies to Purpose categories described in “ Design Patterns: …” by classes or objects Gamma, Helm, Johnson and Vlissides; Addison-Wesley  Classes  Creational  class relations Patterns that can be used to make object creation more flexible  (e.g., Abstract Factory) or restrict creation activities (e.g.,  inheritance structures (static-fixed at compile-time) Singleton).  examples: Factory Method (creation); Adapter Help make a system independent of how objects are created, H l k t i d d t f h bj t t d (structural); Interpreter, Template Method (behavioral) ( t t l) I t t T l t M th d (b h i l)  composed, and represented (i.e., allows one to vary how  Objects objects are created, composed, and represented)  object relations.  Structural  dynamic (can be changed at run-time) Concerned with creating flexible mechanisms for composing   examples: Abstract Factory, Builder, Singleton objects to form larger of structures (creation); Adaptor, Bridge, Facade (structural); Iterator,  Behavioral Observer, Visitor (behavioral) Concerned with creating flexible algorithms and with assigning  responsibilities to classes Eunjee Song Deign Patterns Intro-19 Eunjee Song Deign Patterns Intro-20 Catalog of 23 Design Patterns by GoF  Facade Pattern: Interfacing to subsystems  Observer Pattern: Maintain consistency across Purpose Creational redundant state, also called Publisher-Subscriber Structural Behavioral Class Factory Method Adapter (class) Interpreter  Composite Pattern: Modeling of dynamic aggregates Template Method  Strategy Pattern: Interface to a task implemented by Abstract Factory * Adapter (object) * Chain of Responsibility Prototype Bridge * Command * different algorithms Sco Builder Composite * Iterator * ope  Adapter Pattern: Interface to old systems (legacy Ad t P tt I t f t ld t (l Object Decorator * Singleton Mediator Observer * systems) Facade Flyweight State  Bridge Pattern: Interfacing to existing and future Proxy Strategy * systems Visitor * Scope : domain over which a pattern applies, Purpose : reflects what a pattern does  Proxy Pattern: Reduces the cost of accessing * : patterns to be covered with a Document Editor (Lexi) Example and/or an objects Asteroids game example Eunjee Song Eunjee Song Deign Patterns Intro-21 Deign Patterns Intro-22 Why Study Design Patterns? Why Study Design Patterns? (cont…)  Reuse existing, high-quality solutions to  Improve individual learning and team learning commonly recurring problems  Improve the modification of model/code  Establish common terminology to improve communications within teams  Facilitate adoption of improved design alternatives, even when patterns are not used alternatives even when patterns are not used  Shift the level of thinking to a higher Shift th l l f thi ki t hi h explicitly perspective (i.e., help us see the forest AND the trees)  Decide whether I have the right design, not just one that works. Eunjee Song Eunjee Song Deign Patterns Intro-23 Deign Patterns Intro-24 4