decorator design pattern

• Click to edit Master text styles

– Second level

• Third level

– Fourth level

» Fifth level

Decorator Pattern

Adeel Riaz

Muhammad Shehyyar

Muhammad Owais

Sara Rehmatullah

Ayesha Mehfooz

Advisor: Muhammad Qasim PastaPAF KIET Fall 11PAF-KIET CoCIS Dept.


– Second level

• Third level

– Fourth level

» Fifth level

Concept of Decorating in Real World

Before Decorating

After Decorating

PAF-KIET CoCIS Dept.


– Second level

• Third level

– Fourth level

» Fifth level

Problem??



– Second level

• Third level

– Fourth level

» Fifth level

Decorator Pattern Approach



– Second level

• Third level

– Fourth level

» Fifth level

Problem??


Whenever a team member becomes a team lead, we have to create a new object of team lead and the previous object that points to that employee (team

member) may be destroyed.

Another case is when an employee can perform responsibilities of a team member as well as those of a team lead or a manager can perform team leads responsibilities. In that case you need to create two objects for the

same employee which is totally wrong.


– Second level

• Third level

– Fourth level

» Fifth level

Decorator Pattern Approach


Now, if we want to change responsibilities of an employee to manager we just need a new Manager (Decorator) and assigning that employee to it will solve our problem. Same is the case when a team lead’s responsibilities are revoked, and some other member becomes team lead,

we just need to swap employee objects within TeamMember and TeamLead decorators.


– Second level

• Third level

– Fourth level

» Fifth level

Intent

The Decorator Pattern attaches additional

responsibilities to an object dynamically.

Decorators provide a flexible alternative to

Sub-classing for extending functionality.



– Second level

• Third level

– Fourth level

» Fifth level

Motivation

• Sometimes we want to add responsibilities to individual

objects not to an entire class.

• Inheriting responsibilities from another class attaches

them to every subclass instance statically. This is

inflexible.



– Second level

• Third level

– Fourth level

» Fifth level

Graphical user interface toolkit



– Second level

• Third level

– Fourth level

» Fifth level

Structure



– Second level

• Third level

– Fourth level

» Fifth level

Example



– Second level

• Third level

– Fourth level

» Fifth level

Applicability


•To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.

•For responsibilities that can be withdrawn.

•When extension by sub-classing 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 sub-classing.


– Second level

• Third level

– Fourth level

» Fifth level

Participants

• Component (VisualComponent)

defines the interface for objects that can have responsibilities added

to them dynamically.

• ConcreteComponent (TextView)

defines an object to which additional responsibilities can be

attached.

• Decorator

maintains a reference to a Component object and defines an

interface that conforms to Component‘s interface.

• ConcreteDecorator (BorderDecorator, ScrollDecorator)

adds responsibilities to the component.



– Second level

• Third level

– Fourth level

» Fifth level

Participants



– Second level

• Third level

– Fourth level

» Fifth level

Collaborations


•Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.


– Second level

• Third level

– Fourth level

» Fifth level

Consequences

• More flexible than static inheritance.

• Avoids feature laden classes high up in hierarchy.

• Lots of little objects that look alike. So it is hard to learn and debug.

• A decorator and its components are not identical. So checking object identification can cause problems.



– Second level

• Third level

– Fourth level

» Fifth level

Implementation

Several issues should be considered when applying the Decorator pattern:

1. Interface conformance:

A decorator object’s interface must conform to the interface of the

component it decorates.

2. Omitting the abstract Decorator class:

If only one responsibility is needed, don’t define abstract Decorator.

Merge Decorator’s responsibility into the ConcreteDecorator.

3. Keeping Component classes light weight:

Component class should be dedicated to defining an interface, no other

functions. Keep it light and simple. A complex Component class might make

Decorator too costly to use in quantity.

4. Changing the skin of an object versus its guts:

Decorator classes should act as a layer of skin over an object. If there’s a need

to change the object’s guts, use Strategy pattern.



– Second level

• Third level

– Fourth level

» Fifth level

Builder VS Decorator



– Second level

• Third level

– Fourth level

» Fifth level


Builder VS Decorator


– Second level

• Third level

– Fourth level

» Fifth level

Related Patterns


•Adapter: A decorator is different from an adapter in that a decorator only changes an object‘s responsibilities, not its interface; an adapter will give an object a completely new interface.

•Strategy : A decorator lets you change the skin of an object; a strategy lets you change the guts. These are two alternative

ways of changing an object.

decorator design pattern

Software