This document provides an overview and introduction to design patterns. It discusses creational, structural, and behavioral patterns. For each category it briefly introduces and describes the intent and use of some common patterns, including Factory Method, Singleton, Decorator, Facade, Command, Iterator, and Observer. It also includes diagrams to illustrate the relationships between objects in sample implementations.
Je vous partage l'un des présentations que j'ai réalisé lorsque j'étais élève ingénieur pour le module 'Anglais Business ' , utile pour les étudiants souhaitant préparer une présentation en anglais sur les Design Pattern - ou les patrons de conception .
Je vous partage l'un des présentations que j'ai réalisé lorsque j'étais élève ingénieur pour le module 'Anglais Business ' , utile pour les étudiants souhaitant préparer une présentation en anglais sur les Design Pattern - ou les patrons de conception .
Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.
in these slides i have explained the Abstract Factory Design pattern. slides includes definition, explanation and then implementation by code examples.
Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.
in these slides i have explained the Abstract Factory Design pattern. slides includes definition, explanation and then implementation by code examples.
This slide deck that Mr. Minh Tran - KMS's Software Architect shared at "Java-Trends and Career Opportunities" seminar of Information Technology Center of HCMC University of Science.
Software Design Patterns. Part I :: Structural PatternsSergey Aganezov
In a nutshell, software design patterns are generally reusable solutions to a commonly occurring problems. And this says it all! We are going to learn when it is completely unnecessary for you to reinvent the wheel, and what are the best ways to approach each particular problem during software development process.
What are design principles and how are they different from design patterns?
Why we use design principles?
Some Design principles for an idea.
What are design patterns and their grouping into
Creational Patterns
Structural Patterns
Behavioral Patterns
Conclusion.
Dependency injection via annotations v1.0Jerry Kurian
How annotation works and how frameworks use it to implement dependency injection. The slides also show the concept of compartmentalization and how dependency injection helps with it.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
4. Intro to Design Patterns
• OO Principles
– Encapsulate what varies
– Favor composition over inheritance
– Program to interfaces, not implementations
– Strive for loosely coupled design between objects
and interact
– Only talk to your friends
2/7/2012 Design Pattern Tutorials 4
5. Intro to Design Patterns
• OO Principles (cont.)
– Classes should be open for extension but closed
for modification
– Depend on abstraction. Do not depend on
concrete classes
– Don’t call us, we’ll call you
– A class should have one reason to change
2/7/2012 Design Pattern Tutorials 5
6. Intro to Design Patterns
• OO rules:
– A class A extends (inherits) a class B
(A: subclass, B: superclass)
– An interface extends an interface
– A class implements an interface
– Inheritance -> IS relationship
– Composition -> HAS relationship
2/7/2012 Design Pattern Tutorials 6
7. Intro to Design Patterns
• What is Pattern?
– Pattern is a solution to a problem in a context
– Context: the situation in which the pattern apply
– Problem: goal you are trying to achieve in this
context (any constraints that occur in that context)
– Solution: what you are after – general design that
anyone can apply which resolves the goal and set
of constraints
2/7/2012 Design Pattern Tutorials 7
10. Content
Intro to Design Patterns
Creational Patterns (A)
Structural Patterns (B)
Behavioral Patterns (C)
Other stuffs and conclusion
2/7/2012 Design Pattern Tutorials 10
11. Creational Patterns
Singleton Abstract Factory
Creational Patterns involve object instantiation
and all provide a way to decouple a client from the
objects it needs to instantiate
2/7/2012 Design Pattern Tutorials 11
12. Factory Method Pattern
• Intent: defines an interface for creating an object,
but let subclasses decide which class to instantiate.
Factory Method let a class defer instantiation to
subclasses.
• Use the Factory Method pattern when:
– a class can't anticipate the class of objects it must create.
– a class wants its subclasses to specify the objects it
creates.
– classes delegate responsibility to one of several helper
subclasses, and you want to localize the knowledge of
which helper subclass is the delegate.
2/7/2012 Design Pattern Tutorials 12
14. Factory Method Pattern (cont.)
• Notes:
– Also known as Virtual Constructor
– Encapsulate objects creation
– Rely on inheritance, object creation is delegated to
subclasses with implement the factory method to
create objects.
– Promote loose coupling by reducing the dependency
of your application to concrete classes
– Are powerful technique for coding abstraction, not
concrete classes
2/7/2012 Design Pattern Tutorials 14
15. Abstract Factory Pattern
• Intent: Provides an interface for creating families of
related or dependent objects without specifying
their concrete classes
• Use the Abstract Factory pattern when:
– a system should be independent of how its products are
created, composed, and represented.
– a system should be configured with one of multiple
families of products.
– a family of related product objects is designed to be used
together, and you need to enforce this constraint.
– you want to provide a class library of products, and you
want to reveal just their interfaces, not their
implementations.
2/7/2012 Design Pattern Tutorials 15
17. Abstract Factory Pattern (cont.)
• Notes:
– Also known as KIT
– Rely on composition, object creation is
implemented in methods exposed in the factory
interface
– Others like Factory Method!
2/7/2012 Design Pattern Tutorials 17
18. Singleton Pattern
• Intents: Ensure a class only has one instance, and
provide a global point of access to it.
• Use the Singleton pattern when
– there must be exactly one instance of a class, and it must
be accessible to clients from a well-known access point.
– when the sole instance should be extensible by
subclassing, and clients should be able to use an extended
instance without modifying their code.
– Be careful with multithread!
2/7/2012 Design Pattern Tutorials 18
20. Content
Intro to Design Patterns
Creational Patterns (A)
Structural Patterns (B)
Behavioral Patterns (C)
Other stuffs and conclusion
2/7/2012 Design Pattern Tutorials 20
21. Structural Patterns
Decorator Adapter Façade Composite Proxy
Structural Patterns let you compose classes or
objects into larger structures
2/7/2012 Design Pattern Tutorials 21
22. Decorator Pattern
• Intent: Attach additional responsibilities to an object
dynamically. Decorators provide a flexible alternative
to subclassing for extending functionality.
• Use Decorator:
– to add responsibilities to individual objects dynamically
and transparently, that is, without affecting other objects.
– for responsibilities that can be withdrawn.
– when extension by subclassing is impractical. Sometimes a
large number of independent extensions are possible and
would produce an explosion of subclasses to support every
combination. Or a class definition may be hidden or
otherwise unavailable for subclassing.
2/7/2012 Design Pattern Tutorials 22
24. Decorator Pattern (cont.)
• Notes:
– Also known as Wrapper
– Decorator classes are the same type as the
components they decorate, either through inheritance
or interface implementation.
– You can wrap a component with any number of
decorators.
– Decorators can result in many small objects in our
design, and overuse can be complex.
– Decorators are typically transparent to the client of
the component
2/7/2012 Design Pattern Tutorials 24
25. Adapter Pattern
• Intent: convert the interface of a class into another
interface clients expect. Adapter lets classes work
together that couldn't otherwise because of
incompatible interfaces.
• Use the Adapter pattern when:
– you want to use an existing class, and its interface does not
match the one you need.
– you want to create a reusable class that cooperates with
unrelated or unforeseen classes, that is, classes that don't
necessarily have compatible interfaces.
– (object adapter only) you need to use several existing
subclasses, but it's impractical to adapt their interface by
subclassing every one. An object adapter can adapt the
interface of its parent class.
2/7/2012 Design Pattern Tutorials 25
27. Adapter Pattern (cont.)
• Notes:
– Implementing an adapter may require little work
or a great deal of work depending on the size and
complexity of the target interface
– Adapter Pattern has 2 forms: object and class
adapters. Class adapters require multiple
inheritance
– Adapter wraps an object to change its interface, a
decorator wraps an object to add new behaviors
and responsibilities
2/7/2012 Design Pattern Tutorials 27
28. Facade Pattern
• Intent: 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.
• Use the Facade pattern when:
– you want to provide a simple interface to a complex
subsystem.
– there are many dependencies between clients and the
implementation classes of an abstraction. you want to
layer your subsystems.
– Use a facade to define an entry point to each subsystem
level. If subsystems are dependent, then you can simplify
the dependencies between them by making them
communicate with each other solely through their facades.
2/7/2012 Design Pattern Tutorials 28
30. Facade Pattern (cont.)
• Notes:
– A façade decouple a client from complex system
– Implementing a façade requires that we compose
the façade with its subsystem and use delegation
to perform the work of the façade.
– You can implement more than one façade for a
subsystem.
– A façade wraps a set of objects to simplify
2/7/2012 Design Pattern Tutorials 30
31. Composite Pattern
• Intent: Compose objects into tree structures to
represent part-whole hierarchies. Composite lets
clients treat individual objects and compositions of
objects uniformly.
• Use the Composite pattern when:
– you want to represent part-whole hierarchies of objects.
– you want clients to be able to ignore the difference
between compositions of objects and individual objects.
Clients will treat all objects in the composite structure
uniformly.
2/7/2012 Design Pattern Tutorials 31
33. Composite Pattern (cont.)
• Notes:
– A composition provides a structure to hold both
individual (leaf nodes) objects and composites
– There are many design tradeoffs in implementing
Composite. You need to balance transparency and
safety with your needs
2/7/2012 Design Pattern Tutorials 33
34. Proxy Pattern
• Intent: Provide a surrogate or placeholder for
another object to control access to it.
• Use the Composite pattern when:
– you want to represent part-whole hierarchies of objects.
– you want clients to be able to ignore the difference
between compositions of objects and individual objects.
Clients will treat all objects in the composite structure
uniformly.
2/7/2012 Design Pattern Tutorials 34
36. Proxy Pattern (cont.)
• Notes:
– Also known as Surrogate
– The Decorator Pattern adds behavior to an object,
while a Proxy controls access
– Like any wrapper, proxies will increase the number
of classes and objects in your designs
– Types of proxy: Remote proxy, virtual proxy,
protection proxy
2/7/2012 Design Pattern Tutorials 36
37. Content
Intro to Design Patterns
Creational Patterns (A)
Structural Patterns (B)
Behavioral Patterns (C)
Other stuffs and conclusion
2/7/2012 Design Pattern Tutorials 37
38. Behavioral Patterns
Strategy Command Observer
Iterator
State Template
Behavioral Patterns: concerned with how classes and objects
interact and distribute responsibility
2/7/2012 Design Pattern Tutorials 38
39. Command Pattern
• Intent: Encapsulate a request as an object, thereby
letting you parameterize clients with different
requests, queue or log requests, and support
undoable operations.
• Use the Command pattern when you want to:
– parameterize objects by an action to perform, as
MenuItem objects did above.
– specify, queue, and execute requests at different times.
– support undo. The Command's Execute operation can
store state for reversing its effects in the command itself.
– support logging changes so that they can be reapplied in
case of a system crash.
– structure a system around high-level operations built on
primitives operations.
2/7/2012 Design Pattern Tutorials 39
41. Command Pattern (cont.)
• Notes:
– Also Known As Action, Transaction
– In practice, it is not uncommon for “smart”
Command objects to implement the request
themselves rather than delegating to a receiver.
– Commands may also be used to implement
logging and transactional systems.
2/7/2012 Design Pattern Tutorials 41
42. Iterator Pattern
• Intent: Provide a way to access the elements of an
aggregate object sequentially without exposing its
underlying representation.
• Use the Iterator pattern:
– to access an aggregate object's contents without
exposing its internal representation.
– to support multiple traversals of aggregate objects.
– to provide a uniform interface for traversing different
aggregate structures (that is, to support polymorphic
iteration).
2/7/2012 Design Pattern Tutorials 42
44. Iterator Pattern (cont.)
• Notes:
– Also known as Cursor
– When using an Iterator, we relieve the aggregate
of the responsibility of supporting operations for
traversing its data.
– An Iterator provides a common interface for
traversing the items of an aggregate, allowing you
to use polymorphism when writing code that
makes use of the items of the aggregate
2/7/2012 Design Pattern Tutorials 44
45. Template Pattern
• Intent: define the skeleton of an algorithm in an
operation, deferring some steps to subclasses. Template
Method lets subclasses redefine certain steps of an
algorithm without changing the algorithm's structure.
• The Template Method pattern should be used:
– to implement the invariant parts of an algorithm once and leave
it up to subclasses to implement the behavior that can vary.
– when common behavior among subclasses should be factored
and localized in a common class to avoid code duplication.
– to control subclasses extensions. You can define a template
method that calls "hook" operations (see Consequences) at
specific points, thereby permitting extensions only at those
points.
2/7/2012 Design Pattern Tutorials 45
47. Template Pattern
• Notes:
– Hooks are methods that do nothing or default
behavior in the abstract class, but may be overridden
in the subclass
– To prevent subclasses from changing the algorithm in
the template method, declare the template method
as final
– The Strategy and Template Method Patterns both
encapsulate algorithms, one by inheritance and one
by composition
– The Factory Method is a specialization of Template
Method
2/7/2012 Design Pattern Tutorials 47
48. Observer Pattern
• Intent: define a one-to-many dependency between objects so
that when one object changes state, all its dependents are
notified and updated automatically.
• Use the Observer pattern in any of the following situations:
– When an abstraction has two aspects, one dependent on the other.
Encapsulating these aspects in separate objects lets you vary and
reuse them independently.
– When a change to one object requires changing others, and you don't
know how many objects need to be changed.
– When an object should be able to notify other objects without making
assumptions about who these objects are. In other words, you don't
want these objects tightly coupled.
2/7/2012 Design Pattern Tutorials 48
50. Observer Pattern (cont.)
• Notes:
– Also known as Dependents, Publish-Subscribe
– You can push or pull data from the Observable
when using the pattern
– Don’t depend on a specific order of notification
for your Observers.
– Java has several implementations of the Observer
Pattern, including the general purpose
java.util.Observable
2/7/2012 Design Pattern Tutorials 50
51. Strategy Pattern
• Intent: define a family of algorithms, encapsulate
each one, and make them interchangeable. Strategy
lets the algorithm vary independently from clients
that use it.
• Also known as Policy
• Use the Strategy pattern when:
– many related classes differ only in their behavior.
Strategies provide a way to configure a class with one of
many behaviors.
– you need different variants of an algorithm.
– an algorithm uses data that clients shouldn't know about.
Use the Strategy pattern to avoid exposing complex,
algorithm-specific data structures.
– Instead of many conditionals, move related conditional
2/7/2012 branches into their own Pattern Tutorials class.
Design Strategy 51
53. State Pattern
• Intent: allow an object to alter its behavior when its
internal state changes. The object will appear to change
its class.
• Use the State pattern in either of the following cases:
– An object's behavior depends on its state, and it must change its
behavior at run-time depending on that state.
– Operations have large, multipart conditional statements that
depend on the object's state. This state is usually represented
by one or more enumerated constants. Often, several
operations will contain this same conditional structure. The
State pattern puts each branch of the conditional in a separate
class. This lets you treat the object's state as an object in its own
right that can vary independently from other objects.
2/7/2012 Design Pattern Tutorials 53
55. State Pattern
• Notes:
– Also known as Objects for States
– The Context gets its behavior by delegating to the
current state object is composed with.
– The State and Strategy Patterns have the same
class diagram, but they differ in intent.
– Using the State Pattern will typically result in a
greater number of classes in your design
– State classes may be shared among Context
instances
2/7/2012 Design Pattern Tutorials 55
56. Content
Intro to Design Patterns
Creational Patterns (A)
Structural Patterns (B)
Behavioral Patterns (C)
Other stuffs and conclusion
2/7/2012 Design Pattern Tutorials 56
57. Pattern of pattern
• Pattern are often used together and combined
within the same design solution
• Compound pattern combines two or more
patterns into a solution that solves a recurring
or general problem
• The Model View Controller Pattern (MVC) is a
compound pattern consisting of the Observer,
Strategy and Composite patterns.
2/7/2012 Design Pattern Tutorials 57
62. Other Design Patterns
• Prototype (A) • Interpreter (C)
• Builder (A) • Mediator (C)
• Bridge (B) • Memento (C)
• Flyweight (B) • Visitor (C)
• Chain of responsibility (C)
Look up them more in the Head First
Design Pattern book for more details!
2/7/2012 Design Pattern Tutorials 62
64. Conclusion
Purpose Design Pattern Aspect(s) That Can Vary
Creational Abstract Factory families of product objects
Factory Method subclass of object that is instantiated
Singleton the sole instance of a class
Structural Adapter interface to an object
Composite structure and composition of an object
Decorator responsibilities of an object without
subclassing
Facade interface to a subsystem
Proxy how an object is accessed; its location
2/7/2012 Design Pattern Tutorials 64
65. Conclusion (cont.)
Purpose Design Pattern Aspect(s) That Can Vary
Command when and how a request is fulfilled
Iterator how an aggregate's elements are accessed,
traversed
Observer number of objects that depend on another
object; how the dependent objects stay up
Behavioral to date
State states of an object
Strategy an algorithm
Template steps of an algorithm
Method
2/7/2012 Design Pattern Tutorials 65
66. Conclusion (cont.)
• Design Patterns (DP) aren’t set in stone, adapt
and tweak them to meet your needs
• Always use the simplest solution that meets
your needs, even if it doesn’t include a pattern
• Study DP catalogs to familiarize yourself with
patterns and the relationship among them
• Most patterns you encounter will be adaptations
of existing patterns, not new pattern
2/7/2012 Design Pattern Tutorials 66
67. References
• Head First Design Patterns – by Elisabeth
Freeman, Eric Freeman, Bert Bates, Kathy
Sierra, Elisabeth Robson - O'Reilly Media
(2004)
• Design Patterns: Elements of Reusable
Object-Oriented Software – by Gang of Four -
Addison-Wesley Professional (1994)
2/7/2012 Design Pattern Tutorials 67
68. The End of Design Patterns Tutorials
THANKS FOR LISTENING
Editor: Nguyễn Đức Minh Khôi
@Feb 2012, HCMC University of Technology
Email: nguyenducminhkhoi@gmail.com
2/7/2012 Design Pattern Tutorials 68