Welcome to the Design Pattern for Beginners article series. If this is your first article in this series, I recommend you go through my previous articles on the same topic; they are:
- Design Pattern For Beginners - Part 1: Singleton Design Pattern
- Design Pattern For Beginners - Part 2: Factory Design Pattern
- Design Pattern For Beginners - Part 3: Prototype Design Pattern
- Design Pattern For Beginners - Part 4: Decorator Design Pattern
- Design Pattern For Beginners - Part 5: Composite Design Pattern
- Design Pattern For Beginners - Part 6: Adaptor Design Pattern
- Design Pattern For Beginners - Part 7: Bridge Design Pattern
- Design Pattern For Beginners - Part 8: memento Design Pattern
- Design Pattern for Beginners - Part-9: Strategy Design Pattern
- Design Pattern for Beginners - Part-10: Observer Design Pattern
- Design Pattern For Beginners - Part 11: Implement Decouple Classes in Application
This article explains one more very popular structural design pattern called the Decorator Design Pattern. The name itself implies that this is something related to decoration. Yes, in the Decorator Design Pattern we will be implementing one object in through various steps and in each and every step we will add a little feature to it.
Why decorator pattern?
Before beginning the technical discussion and examples we will learn the basics of the Decorator Design Pattern and the primary need for it.
If there is a need to produce one object with many features but not all the features are needed all the time then the Decorator Design Pattern is useful. For example think about a car beautification shop. Where a new car goes to and according to the owner's demand the shop owner beautifies their car.
One owner may like to fit AC into his car where another owner may not like AC, he might instead want a sound system (Hmm, he likes music..) in his new car. Now, the shop owner has all the facilities, and according to car owner's demand he decorates the car. This is where the Decorator Design Pattern can be a solution.
Let's implement our car problem using the Decorator Design Pattern. Have a look at the following code:
- using System;
- using System.Collections;
- using System.Globalization;
- using System.Data.SqlClient;
- using System.Data;
- namespace Test1
- {
- public class Car
- {
- public virtual void CarType()
- {
- Console.WriteLine("Simple Car");
- }
- }
- public class WithAC : Car
- {
- public override void CarType()
- {
- //base.CarType();
- Console.Write("AC Car");
- }
- }
- public class WithSoundSystemAndAC : WithAC
- {
- public override void CarType()
- {
- base.CarType();
- Console.WriteLine("with Sound system");
- }
- }
- class Program
- {
- static void Main(string[] args)
- {
- Car objCarAC = new WithAC();
- objCarAC.CarType();
- Console.WriteLine("\n");
- Car objCarAll = new WithSoundSystemAndAC();
- objCarAll.CarType();
- Console.ReadLine();
- }
- }
- }
Now, if anyone needs only AC for their Car then he will be happy by creating an object from the WithAC class. And if you want to fit both an AC and Sound system into your car then just create one object from the WithSoundSystemAndAC class. With this implementation the shop owner can make everyone happy. Here is the sample output.

Now, you may ask the question, what if someone demands only a Sound System in his car but not AC. The solution is derive one class from the Car class where we will implement only a Sound System, no other facility (in other words AC). Here is the simple implementation, the same as the WithAC class.
- public class WithSoundSystem:Car
- {
- public override void CarType()
- {
- //base.CarType();
- Console.Write("Car with only sound system");
- }
- }

Radjin MissierPosted Jun 17, 2019, 7:18 PM
This is incorrect, the decorator pattern has a isa and hasa relationship with the decorated object. The decorator object uses the inner object for behaviour and modifies this behaviour if necessary. Example:public interface ICar { string GetDescription(); } public class Car : ICar { string _description; public Car() { _description = "basic car"; } public string GetDescription() { return _description; } } public abstract class CarDecoractor : ICar { private ICar _car; public CarDecoractor(ICar car) { _car = car; } public virtual string GetDescription() { return _car.GetDescription() + " + "; } } public class AircoDecorator : CarDecorator { public AircoDecorator(ICar car) : base(car) {} public override string GetDescription() { return base.GetDescription() + "AirConditioning"; } } public class SoundDecorator : CarDecoractor { public SoundDecorator(ICar car) : base(car) {} public override string GetDescription() { return base.GetDescription() + "SoundSystem"; } } public class Program { static void Main() { ICar car = new Car(); Console.WriteLine(car.GetDescription()); ICar ac_car = new AircoDecorator(car); Console.WriteLine(ac_car.GetDescription()); ICar ss_car = new SoundDecorator(car); Console.WriteLine(ss_car.GetDescription()); ICar all_car = new AircoDecorator(new SoundDecorator(car)); Console.WriteLine(all_car.GetDescription()); } }
Ana-Maria CiufuPosted Mar 27, 2019, 11:03 AM
This explanation is wrong in my opinion. The decorator pattern tries to avoid exactly the approach shown in these examples - making all the possible combinations of options which leads to a explosion of classes. The Decorator pattern works in a recursive manner. See this video for details: https://www.youtube.com/watch?v=GCraGHx6gso
sparkle daiPosted Aug 30, 2013, 7:36 PM
Simple and clearly!Ver good!