Design patterns in brief
29
description
This presentation shows some basics of design patterns and explanation of some common used design patterns such as Singleton, Observer, Command, etc.
Transcript of Design patterns in brief
What are design patterns?
They› are common ways of structuring programs› typically deal with a small number of
classes, but can be of any size› provide a communication framework in
which ideas can be discussed at a high level
› can specify how objects are created, how they interact, or how they are structured
Why design patterns?
Reuse solutions Vocabulary for development Better software
Who?
Alexandre Christopher ‘Gang of Four’: Erich Gamma, Richard
Helm, Ralph Johnson, and John M. Vlissides
What?
Gang of Four common design patterns Some new J2EE design patterns
How can design patterns be derived?
They do use the Design Principles
Programming to interfaces not implementations Favor composition over inheritance Encapsulate what varies Strive for loosely coupled between objects that interact Classes should OPEN for extension and CLOSE for
modification Depends on abstraction, not concrete classes Don't call us, we'll call you A class should have only one reason to change
Com
mon
patte
rns
Desig
n Pa
ttern
sC
ate
gorie
s
Singleton Builder Factory method Facade Decorator Observer Command Strategy
Creational: How to create objects (higher level than constructors)
Behavioral: Describing how objects interact
Structural: Common relationships in class diagrams
C
BS
Singleton
public static Counter getInstance() { if(uInstance == null) { this.uInstance = new Counter(); return this.uInstance; } else { return this.uInstance; }}
C
The purpose of Singleton
› Makes sure only one instance of an object exists within an application.
› A better solution compared to global variables
› Provide global access to the object instance.
› Example: Counter, Application Menu System, Application objects, Services, Clients
› Not as easy as you think: What about threading?
Factory Method
Defines an interface for creating an object but lets subclasses decide which class to instantiate.
Lets classes defer instantiation to subclasses
C
Benefits of Factories
We can choose what to instantiate at runtime
We can code to an interface› Don’t have to know exactly what kind of
object we’ll get back We centralize code
› In order to add new types of objects, we only have to modify one place, the factory
12
Builder C
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Façade
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.(GoF)
S
The DBFacade Example Common JDBC uses:
› Open a connection to DB
› Close a connection› Get all tables from
DB› Executes a SQL
statement› Retrieve result from
a SELECT statementAll That I Need
DatabaseFacade Outlook
JDBC APIDatabaseFacade
Clientuses
Connection
Statement
ResultSet
DatabaseMetadata
ResultSetMetadata
Driver…
Decorator
BufferedReader in = new BufferedReader(new FileReader(“foo.in"));
S
Strategy B
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it
Observer
GoF
B
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
MVC
What does it hire?
Command B
“Let’s hide (encapsulate) the way we call (invoke) methods.”
Example: Menus
Consider an application menu system. How do we de-couple our menu system from our document class?
Command Interface
Client
We can do a lot of things (actions) with a document. Each interface might be different!
Receiver
ConcreteCommandMenu contains many menu items.
Composite Pattern!
invoker
AllGoF patterns
J2EE patterns
Categorized by tiers: Presentation Tier Business Tier Integration Tier
Data Access Object
Alur et al.
Business Objects
Alur et al.
Session Façade
Alur et al.
Application Service
Alur et al.
References
E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software. Addison-Wesley, Boston, 1995.
D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, 2003
