DESIGN PATTERN

Group 10 Vu Khanh Hoang

Nguyen Ngoc Quang Huy
Dao Tan Hao
Mai Pham Quoc Hung
 TABLE OF CONTENTS

DESIGN
01 PATTERN 02 VISITOR 03 FLYWEIGHT
 01
DESIGN PATTERN
DESIGN PATTERN
A solution to a common software problem in a context
○ Describes a recurring software structure
○ Abstract from programming language
○ Identifies classes and their roles in the solution to a
problem
○ Patterns are not code or designs; must be
instantiated/applied
 BENEFITS

Patterns are a Patterns capture design Improve documentation (less

common design expertise and allow that is needed) and
vocabulary expertise to be understandability (patterns
communicated are described well once)
 02
VISITOR
PATTERN
PROBLEM
PROBLEM
WHAT IS VISITOR PATTERN?

● Allows for new operations to be

defined and used on elements of an
object structure with out changing the
contents of those elements.
● The Key is Double Dispatch
 APPLICABLE

Rarely Changing Using Unrelated Many Classes with

Object Structures Operations Differing Interfaces
SINGLE DISPATCH & DOUBLE DISPATCH

• Single dispatch is when a method is polymorphic

on the type of one parameter (including the
implicit this).

• Double dispatch is polymorphism on two

parameters.
 Visitor

The Visitor interface declares a
set of visiting methods:
• Can take concrete elements of
an object structure as
arguments
• May have the same names if
the program is written in a
language that supports
overloading
• The type of their parameters
must be different.

STRUCTURE
 Concrete Visitor
Each Concrete
Visitor implements several
versions of the same behaviors.
 Element
The Element interface declares a
method for “accepting” visitors.
This method should have one
parameter declared with the type
of the visitor interface.
 Concrete Element
Each Concrete Element must
implement the acceptance method.
Purpose: redirect the call to the proper
visitor’s method corresponding to the
current element class.
Even if a base element class
implements this method, all subclasses
must still override this method in their
own classes and call the appropriate
method on the visitor object.
 Client
The Client usually represents a
collection or some other complex
object (for example, a Composite
 tree).
Clients work with objects from that
collection via some abstract interface
=> Usually, they aren’t aware of all the
concrete element classes
 PROS AND CONS
 Open/Closed Principle. You can  You need to update all visitors each time
introduce a new behavior that can a class gets added to or removed from the
work with objects of different classes element hierarchy.
without changing these classes.  Visitors might lack the necessary access
 Single Responsibility Principle. You to the private fields and methods of the
can move multiple versions of the elements that they’re supposed to work
same behavior into the same class. with.
 A visitor object can accumulate
some useful information while
working with various objects. This
might be handy when you want to
traverse some complex object
structure, such as an object tree, and
apply the visitor to each object of
this structure.
 DEMO
Single Dispatch Double Dispatch (Visitor)
 DEMO
With Visitor
Without Visitor
 DEMO
With Visitor
Without Visitor
 03
FLYWEIGHT
PATTERN
Problem
 What is flyweight pattern?

• A pattern for sharing objects

• Each instance does not contain its own state but stores it
externally.

• This allows efficient sharing of objects to save space when

there are many instances but only a few different types.

• Main advantage of flyweight design pattern is that, it reduces

memory consumption by controlling the amount object creation.
Intrinsic – state
that naturally Extrinsic – state
belongs to the that belongs to
‘Flyweight’ object
and thus should be
the context of the
permanent or project (external)
immutable (internal) or unique to that
or context free instance
Generic UML Diagram Flyweight
Generic UML Diagram Flyweight
 STRUCTURE

1. Flyweight 2. Flyweight factory 3.Clients

Declares an interface through Creates and manages flyweight objects. Maintains a reference to
which flyweights can receive Ensures that flyweights are shared properly. flyweight(s). Computes or
and act on extrinsic state. When a client requests a flyweight, the stores the extrinsic state of
Flyweight Factory object supplies an flyweight(s)
existing instance or creates one, if none
exists.
 3. Concrete Flyweight 4. Unshared Concrete
(Character) Flyweight
• Implements the Flyweight interface and adds • Not all Flyweight subclasses need to be shared.
storage for intrinsic state, if any. • The Flyweight interface enables sharing; it
• A ConcreteFlyweight object must be sharable. doesn't enforce it.
• Any state it stores must be intrinsic; that is, it must • It’s common for Unshared Concrete Flyweight
be independent of the ConcreteFlyweight object's objects to have Concrete Flyweight objects as
context. children at some level in the flyweight object
structure (as the Row and Column classes
have).
 ADVANTAGE AND DISADVANTAGE
Advantage
● Reduce the number of objects created by sharing objects. So save memory and necessary storage
devices

● Improved data cache because of fast response time

● Increase System Performance

Disadvantage
● Trade-off in terms of CPU usage when flyweight objects are accessed
multiple times.
● The code becomes much more complicated

When it is a good idea

● Facing memory constraints and get thousands of similar objects.
 Example:
A game application includes many Soliders, divided into categories: Yuri, Spy, Doctor,
etc. Each Solider will have a different id and level. Time to create a Solider type is 3 seconds.
Context.java ISoldier.java
Soldier.java
SoldierF
actory.ja
va
GameApp.java
Output
THANKS!
Any question?