Decorator design pattern falls under the category of Structural Design Pattern. Structural design pattern emphasizes upon the overall structure of classes and objects in the system either by doing class inheritance or by composing objects into larger structures using object composition. Decorator pattern comes in handy when we want to add additional responsibilities to the object during run time.
-
Additional responsibilities can be added statically by class inheritance also. But this will create another problem when we want to add such responsibilities to objects of many classes. We may have to create many child classes to support additional new functions.
-
So instead of creating many child classes of already existing concrete classes, we create a new Decorator
, and a new Concrete Decorator
class that will add new methods and properties to the existing class object during run time. This way, we are not modifying the existing concrete or legacy classes. Responsibilities to objects can be added during runtime because base class of the object and Decorator
class share the same base type. And Concrete Decorator
class extends the new Decorator
.
This design pattern does not come initially during system design. It generally comes during maintenance phase or later in the development phase.
Now let’s see the example of decorator design pattern. We even use mobile phone to send text and multimedia messages. Once the message is sent, the Outbox becomes empty. But sometimes, we want to save the sent content message. To do this, we need to select the option of “Send and Save”, and any message sent this way will be saved inside “Sent” folders. Here, even if the user may not always want to save the sent messages, it is for sure that he may definitely want to send messages. Keeping this use case in mind, let’s look into such a class design.
Figure: Base class for SMS and MMS Concrete Classes
Figure: Overall class structure after the introduction of Decorator
From the above diagram, we see two main concrete classes that are involved in sending messages - MobileMMS
sends image as message content while MobileSMS
send text. Both of the classes are doing well with SendMessage()
method. SendMessage()
is an abstract
method in BaseMessage
root class. Decorator
, often called DecoratorBase
, can be seen inheriting from the same base type of these two MobileMMS
and MobileSMS
classes, i.e.; inheriting from BaseMessage
class. For a Decorator class, this is important.
Then, we see MessageProcessor
class (often called ConcreteDecorator
) which is a concrete implementation of Decorator
.
Note: BaseMessage
, MobileMMS
and MobileSMS
are the original classes. Only due to SendAndSave
option, a new responsibility SaveMessage()
is now required to be added into the objects of MobileMMS
and MobileSMS
. This is how we see DecoratorBase
and ConcreteDecorator
need to be added later on.
Now let’s see the actual implementation of the classes.
namespace DecoratorPattern
{
abstract class BaseMessage
{
private string _sender;
private string _recipient;
public string MessageSender
{
get
{
return this._sender;
}
set
{
this._sender = value;
}
}
public string MessageRecipient {
get
{
return this._recipient;
}
set
{
this._recipient = value;
}
}
public abstract void SendMessage();
}
}
namespace DecoratorPattern
{
class MobileSMS: BaseMessage
{
private string _message;
public MobileSMS(string strSender, string strRecipient, string strMessage)
{
this.MessageSender = strSender;
this.MessageRecipient = strRecipient;
this.Message = strMessage;
}
public string Message
{
get
{
return this._message;
}
set
{
this._message = value;
}
}
public override void SendMessage()
{
}
}
}
namespace DecoratorPattern
{
class MobileMMS:BaseMessage
{
private byte[] image;
public MobileMMS(string strSender, string strRecipient, byte[] image)
{
this.MessageSender = strSender;
this.MessageRecipient = strRecipient;
this.Image = image;
}
public byte[] Image
{
get
{
return this.image;
}
set
{
this.image = value;
}
}
public override void SendMessage()
{
}
}
}
namespace DecoratorPattern
{
class Decorator: BaseMessage{
protected BaseMessage message;
public Decorator(BaseMessage message)
{
this.message = message;
}
public override void SendMessage()
{
message.SendMessage();
}
}
}
namespace DecoratorPattern
{
class MessageProcessor:Decorator{
public MessageProcessor(BaseMessage message): base(message)
{
}
public void SaveMessage()
{
}
public override void SendMessage()
{
base.SendMessage();
SaveMessage();}
}
}
Now see the SendSMS
and SendMMS
methods: how the constructor methods of MessageProcessor
are accepting object instances. This is called object composition, and important for Concrete Decorator. This way, MessageProcessor
will be able to direct the call to the actual method of the class. See the SendMessage()
method code above in MessageProcessor
.
Client Code
namespace DecoratorPattern
{
class Program
{
public enum SendMessageOption
{
SendOnly = 0,
SendAndSave = 1
}
private void SendSMS(SendMessageOption option)
{
MobileSMS sms = new MobileSMS("123″, "456″,
"This is example of decorator pattern.");
if (option == SendMessageOption.SendOnly)
{
sms.SendMessage();
}
else if (option == SendMessageOption.SendAndSave)
{
MessageProcessor msgProcessor = new MessageProcessor(sms);
msgProcessor.SendMessage();
}
}
private void SendMMS(SendMessageOption option)
{
MobileMMS mms = new MobileMMS("123″, "456″, new byte[] { 1, 2, 3, 4 });
if (option == SendMessageOption.SendOnly)
{
mms.SendMessage();
}
else if (option == SendMessageOption.SendAndSave)
{
MessageProcessor msgProcessor = new MessageProcessor(mms);
msgProcessor.SendMessage();
}
}
static void Main(string[] args)
{
Program obj = new Program();
obj.SendSMS(SendMessageOption.SendOnly);
obj.SendSMS(SendMessageOption.SendAndSave);
obj.SendMMS(SendMessageOption.SendOnly);
obj.SendMMS(SendMessageOption.SendAndSave);
Console.Read();
}
}
}
Hope the Decorator design pattern is now simple enough to understand.