Introduction o to Patterns and Design Patterns Dept. of Computer Science Baylor University Some slides adapted from slides by R. France and B. Tekinerdogan Observations Engineering=Problem Solving Many yproblems recur. 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 problems faster and better. Fundamental to any engineering discipline (even any science): a common vocabulary for expressing its concepts, and a language for relating them together. Deign Patterns Intro-1 Deign Patterns Intro-2 Electrical Engineering Patterns Mechanical Engineering Patterns Deign Patterns Intro-3 Deign Patterns Intro-4
Chemical Engineering Patterns Software Engineering Patterns Deign Patterns Intro-5 Deign Patterns Intro-6 Origin of the term "pattern Timeless Way of Building (Oxford University Press, 1970) Pattern: Problem-Solution-Context Work on software development patterns stemmed from work on patterns from building architecture carried out by Christopher Alexander. Deign Patterns Intro-7 Deign Patterns Intro-8
What are software patterns? Patterns are intended to capture the best available software development experiences in the form of problem-solution pairs. A pattern outlines solutions to a family of software development problems in a particular context. A pattern outlines a process for transforming problems targeted by the problem to solutions characterized by the pattern. Patterns Solve Software Structural Problems like... Abstraction, Encapsulation Information hiding Separation of concerns Coupling and cohesion Separation of interface and implementation Single point of reference Divide and conquer Deign Patterns Intro-9 Deign Patterns Intro-10 Patterns Solve Non-functional Problems like... Changeability Interoperability Efficiency Reliability Testability Reusability Pattern Types 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 systems, etc. Architectural Patterns: Characterize families of architectures e.g., Broker pattern: can be used to create distributed systems in which location of resources and services is transparent (e.g., the WWW) Other examples: MVC, Pipe-and-Filter, Multi-Tiered Design Patterns: Characterize families of low-level design solutions Examples: Gang of Four (GoF) patterns Programming idioms: Characterize programming language specific solutions Deign Patterns Intro-11 Deign Patterns Intro-12
Example of an Architectural Pattern - Model-View-Controller (MVC) Pattern Context: Developing user-interfaces (UIs ) Problem: How to create a UI that s resilient to changes such as changes in look-and-feel windowing system, changes in functionality. Factors: changes to UI should be easy and possible at run-time; adapting or porting the UI should not impact the implementation of the core functionality. MVC Solution Outline: Split Application into 3 Areas: The Model component: encapsulates core functionality; independent of input/output representations and behavior. The View components: displays data from the model component; there can be multiple views for a single model component. The Controller components: each view is associated with a controller that handles inputs; the user interacts with the system via the controller components. Deign Patterns Intro-13 Deign Patterns Intro-14 Patterns Summary A pattern addresses a recurring software development problem that arises in a particular context, t and outlines a solution for it. A pattern captures best practices in software development (the intention! ). A pattern should be based on actual experiences in industry Patterns provide a common vocabulary for, and understanding of best practices. Developers can refer to a pattern by name (e.g., the Adapter pattern) and others familiar with the pattern will not need further description Patterns, Architectures & Frameworks There can be confusion between patterns, architectures and frameworks. Architectures model software structure at the highest possible level, and give the overall system view. An architecture can use many different patterns in different components Deign Patterns Intro-15 Deign Patterns Intro-16
Patterns, Architectures & Frameworks (cont...) Patterns are more like small-scale or local architectures for architectural components or sub-components Frameworks are partially completed software systems that t may be targeted t at a particular type of application. These are tailored by completing the unfinished components. Summary of Differences Patterns are more general and abstract than frameworks. A pattern is a description of a problem-solution pair, not a solution (or problem) itself. A pattern cannot be directly implemented. An implementation is an example of a pattern. Patterns are more primitive than frameworks. A framework can employ several patterns. Deign Patterns Intro-17 Deign Patterns Intro-18 Gang of 4 (GoF) Design Pattern Classification i Purpose categories described in Design Patterns: by Gamma, Helm, Johnson and Vlissides; Addison-Wesley Creational Patterns that can be used to make object creation more flexible (e.g., Abstract Factory) or restrict creation activities (e.g., Singleton). Help make a system independent of how objects are created, composed, and represented (i.e., allows one to vary how objects are created, composed, and represented) Structural Concerned with creating flexible mechanisms for composing objects to form larger of structures Behavioral Concerned with creating flexible algorithms and with assigning g responsibilities to classes Scope Criterion Scope determines whether a pattern applies to classes or objects Classes class relations inheritance structures (static-fixed at compile-time) examples: Factory Method (creation); Adapter (structural); Interpreter, Template Method (behavioral) Objects object relations. dynamic (can be changed at run-time) examples: Abstract Factory, Builder, Singleton (creation); Adaptor, Bridge, Facade (structural); Iterator, Observer, Visitor (behavioral) Deign Patterns Intro-19 Deign Patterns Intro-20
Scope Catalog of 23 Design Patterns by GoF C lass Obje ect Purpose Creational Structural Behavioral Factory Method Adapter (class) Interpreter Template Method Abstract Factory Adapter (object) Chain of Responsibility Prototype Bridge Command Builder Composite Iterator Singleton Decorator Mediator Facade Observer Flyweight State Proxy Strategy Visitor it Scope: domain over which a pattern applies, Purpose: reflects what a pattern does : patterns to be covered with a Document Editor (Lexi) Example and/or an At Asteroids game example Facade Pattern: Interfacing to subsystems Observer Pattern: Maintain consistency across redundant state, also called Publisher-Subscriber Composite Pattern: Modeling of dynamic aggregates Strategy Pattern: Interface to a task implemented by different algorithms Adapter Pattern: Interface to old systems (legacy systems) Bridge Pattern: Interfacing to existing and future systems Proxy Pattern: Reduces the cost of accessing objects Deign Patterns Intro-21 Deign Patterns Intro-22 Why Study Design Patterns? Reuse existing, high-quality solutions to commonly recurring problems Establish common terminology to improve communications within teams Shift the level of thinking to a higher perspective (i.e., help us see the forest AND the trees) Decide whether I have the right design, not just one that works. Why Study Design Patterns? (cont ) Improve individual learning and team learning Improve the modification of model/code Facilitate adoption of improved design alternatives, even when patterns are not used explicitly Deign Patterns Intro-23 Deign Patterns Intro-24