The presentation explains the decorator design pattern using the example of a car manufacturing company, 'uselesscars', which initially faced class explosion issues when adding features to their basic car model. The decorator pattern allows for dynamically adding new functionality to an object without modifying its structure, thereby adhering to the open/close principle. The implementation in C# demonstrates how to utilize this pattern by creating an interface for basic cars and decorators for additional features, allowing for flexible and scalable design.

1. Decorator Design Pattern
A Gift Wrapper
Sameer Singh Rathoud

2. About presentation
This presentation will help in understanding decorator design pattern, it’s
structure and it’s implementation.
I have tried my best to explain the concept in very simple language.
The programming language used for implementation in this presentation is c#. But
any one from different programming background can easily understand the
implementation.

3. Definition
A decorator pattern is a design pattern that allows behavior to be added to an
object dynamically. Decorators provide a flexible alternative to sub-classing for
extending functionality.
Decorator pattern is a structural design pattern.

4. Problem
A car manufacturing company named “UselessCars” came newly in the market. Initially they came up
with a very basic cars with four wheels, a engine and few more basic things.
UselessCarBasic
getCost()
This is a class for our
“UselessCarBasic” with an operation
“getCost()” (will return the cost of
the car).

5. Problem
As the company was not able to sell the cars. They came up with few more features in the car like
“doors” and “seats”.
UselessCarBasic
getCost()
So the “UselessCars” came up with three more classes
“UselessCarWithDoor”, “UselessCarWithseats” and
“UselessCarWithDoorAndSeats” deriving from “UselessCarBasic”.
Here each derive class has implemented operation “getCost()”
Inheritance
UselessCarWithDoor
getCost()
UselessCarWithseats
getCost()
UselessCarWithDoorAndSeats
getCost()

6. Problem
But later the company came up with lots of other features and “UselessCars” class structure met
with the class explosion.
UselessCarBasic
getCost()
Inheritance
UselessCarWithDoor
getCost()
UselessCarWithseats
getCost()
UselessCarWithABS
getCost()
UselessCarWith
AdjustableSeat
getCost()
UselessCarWith
FogLamp
getCost()
UselessCarWithAirBag
getCost()
UselessCarWithMusicSys
getCost()
UselessCarWithDoorAndSeats
getCost()

7. Problem
To solve this class explosion problem the “UselessCar” has changed there structure to a single class
and added operations to add the cost of each features.
UselessCarBasic
AddDoors()
AddSeats()
AddABS()
AddLeatherSeatCovers()
AddLeatherDashBoard()
AddMusicSystem()
AddAirBags()
....
getCost()
Although this is a workable solution. But this class structure is
violating the OO design principle “open/close principle” (open
for extension and close for modification). In this class
structure, every time a new feature is getting launched
“UselessCarBasic” class will get changed (adding a function in
class for adding cost). So we need to look for a better solution
to this problem.

8. Solution
Inheritance
<< interface >>
UselessCar
GetCost()
UselessCarBasic
Inheritance
UselessCar
GetCost()
<< interface >>
UselessCarDecorator
GetCost()
UselessCarWithDoors
GetCost()
UselessCarWithDoors
GetCost()
UselessCarWithABS
GetCost()
UselessCarWithFogLamps
GetCost()
....
GetCost()
In this approach we have created an
interface “UselessCar” which is having
an operation “GetCost()” and created a
class “UselessCarBasic” which is
implementing “UselessCar” and defining
operation “GetCost()”. Here we have
introduced one more interface
“UselessCarDecorator” which is holding a
reference of “UselessCar” and all the
features of “UselessCar” will be
implementing this interface and
providing the definition of operation
GetCost() by adding the cost of the
feature in the cost of “UselessCarBasic”.

9. Motivation and Intent
• The intent of this pattern is to add additional responsibilities dynamically to an
object.
Add addition functionality or state to an individual objects at run-time. Inheritance
is not feasible because it is static and applies to an entire class.

10. Structure
Client
Inheritance
<< interface >>
Component
Operation ()
Operation ()
Concrete Component
Operation ()
<< interface >>
Decorator
Concrete Decorator A
Operation ()
Concrete Decorator B
Operation ()
Inheritance
state AddedBehavior ()
Component

11. Participants in structure
• Component (interface): is a interface for objects for which responsibilities can be added
dynamically.
• Concrete component: concrete implementation of component and will provide the object for
which responsibilities can be added at runtime.
• Decorator (interface): is a interface for additional functionality or state and maintains the
reference to component.
• Concrete decoratorA and Concrete decoratorB: are the classes defining the implementation to
decorator interface and provide the additional functionality.
• Client: The user of the decorator design pattern.

12. Collaborations
• Created a Component and run the Operation() on that. Added a behavior/functionality/state with
concrete component and run the operation on the decorated object, now the behavior will get
changed.
Client Concrete Component Concrete Decorator
new Concrete Component ()
ComponentObject.Operation()
new Concrete Decorator (ComponentObject)
ConcreteDecoratorObject.Operation()

13. Implementation (C#)
Component (Interface)
public abstract class UselessCar
{
public abstract int Cost { get; }
}
Here “UselessCar” is an abstract class with
an abstract property “Cost”. Now all the
concrete classes implementing this abstract
class will override “Cost” method.
<< interface >>
UselessCar
+ Cost ()

14. Implementation (C#)
Concrete Component
class UselessCarBasic: UselessCar
{
public override int Cost
{
get
{
return 1000; //Basic Car Cost
}
}
}
Here a concrete class “UselessCarBasic” is
implementing abstract class “UselessCar”
and these concrete classes is overriding
property “Cost” (giving the cost of
“UselessCarBasic”) of “UselessCar”
class.
<< interface >>
UselessCar
+ Cost ()
UselessCarBasic
Cost()

15. Implementation (C#)
Decorator (interface)
public abstract class UselessCarDecorator : UselessCar
{
public UselessCar uselessCarObj;
public override int Cost
{
get
{
return this.uselessCarObj.Cost;
}
}
public UselessCarDecorator(UselessCar uselessCar)
{
this.uselessCarObj = uselessCar;
}
}
Here an abstract class “UselessCarDecorator”
is implementing abstract class “UselessCar” and
these concrete classes is overriding property
“Cost” of “UselessCar” class and additionally
it is holding a reference of “UselessCar”.
<< interface >>
UselessCar
+ Cost ()
UselessCarBasic
+ Cost()
UselessCarDecorator
+ Cost()
+ UselessCar

16. Implementation (C#)
Concrete Decorator
class UselessCarWithDoors: UselessCarDecorator {
public UselessCarWithDoors(UselessCar uselessCar)
: base(uselessCar) {
}
public override int Cost {
get {
return uselessCarObj.Cost + 200; //Basic Car Cost + Doors cost
}
}
}
“UselessCarWithDoors”
is a concrete class
implementing abstract class
“UselessCarDecorator”
and overriding property
“Cost” of
“UselessCarDecorator”
and it is defining a constructor
expecting a parameter of type
“UselessCar” this
parameter is further passed to
the constructor of base class
(“UselesscarDecorator”).

17. Implementation (C#)
class UselessCarWithSeats : UselessCarDecorator {
public UselessCarWithSeats(UselessCar uselessCar)
: base(uselessCar) {
}
public override int Cost {
get {
return uselessCarObj.Cost + 150; //Basic Car Cost + Seats cost
}
}
}
Here is an another class
“UselessCarWithSeats”
implementing
“UselessCarDecorator”
and overriding property
“Cost” and it is also defining
a constructor expecting a
parameter of type
“UselessCar” this
parameter is further passed to
the constructor of base class
(“UselesscarDecorator”).
Concrete Decorator

18. Implementation (C#)
class UselessCarWithABS : UselessCarDecorator {
public UselessCarWithABS(UselessCar uselessCar)
: base(uselessCar) {
}
public override int Cost {
get {
return uselessCarObj.Cost + 800; //Basic Car Cost + ABS cost
}
}
}
This is one more class
“UselessCarWithABS”
implementing
“UselessCarDecorator”
and overriding property “Cost”
and it is also defining a
constructor expecting a
parameter of type
“UselessCar” this parameter
is further passed to the
constructor of base class
(“UselesscarDecorator”).
Concrete Decorator

19. Implementation (C#)
Client
class Client {
static void Main(string[] args) {
UselessCar uselessCar = new UselessCarBasic();
System.Console.WriteLine(uselessCar.Cost);
UselessCarWithDoors uselessCarWithDoors = new UselessCarWithDoors(uselessCar);
System.Console.WriteLine(uselessCarWithDoors.Cost);
UselessCarWithSeats uselessWithCarDoorsandSeats = new UselessCarWithSeats(uselessCarWithDoors);
System.Console.WriteLine(uselessWithCarDoorsandSeats.Cost);
UselessCarWithABS uselessCarWithABS = new UselessCarWithABS(uselessCar);
System.Console.WriteLine(uselessCarWithABS.Cost);
}
}
For using decorator design pattern the client will create an instance of “UselessCarBasic” and
can add as many features as he wants to by creating the object of features by passing the reference
of “UselessCar” and can perform operation “Cost” on those feature objects.

20. Implementation (C#)
Class Structure << interface >>
UselessCar
+ Cost ()
UselessCarBasic
+ Cost()
UselessCarDecorator
+ Cost()
+ UselessCar
UselessCarWithABS
+ Cost()
UselessCarWithDoors
+ Cost()
UselessCarWithSeats
+ Cost()
Inheritance
Inheritance
Client

21. Example and applicability
GUI framework: GUI framework can use decorator pattern for extending the functionality
dynamically.
Whenever a programmer is having a requirement where he/she has to extend the functionality at
runtime on the top of some basic functionality can opt for decorator design pattern.

22. References
1. Design Patterns: Elements of Reusable Object-Oriented Software
• by Ralph Johnson, John Vlissides, Richard Helm, and Erich Gamma
2. Head First Design Patterns
• Kathy Sierra, Eric Freeman, Elisabeth Freeman, Bert Bates

23. End of Presentation . . .