Decorator Pattern

So, as decided in the introduction post, let us start with the ritual of solving a problem without knowing anything about the pattern.

Problem Statement:

In networks, when data is transmitted over air, it is encrypted with a certain algorithm to ensure security. The client of your company, say, Airtel decided to encrypt their data with 2 algorithms- AES and DES, different type of users can be encrypted by different algorithms. They want you to design their software such that every data packet is encrypted with AES or DES algorithm or not encrypted at all depending on the type of user using the data packet. The guidelines are-

1. There will be two types of users, currently in the system depending on the type of user equipment they are using.
2. Each type of user will have some data to send at some point in time.
3. Depending on the service they use, data may or may not be encrypted.
4. If encrypted, user group1 will use AES encryption and user group2 will use DES encryption.

/* Note that I am using ‘Airtel’ only for illustrative purpose here, Airtel may/may not work on these principles. You can read ‘Airtel’ as any ‘ABC’ company for example. */

Getting Deeper…

First Insight to solving the problem would be to create a class Users that contains all information regarding a user and the operations to be performed on it. Different instances of this class shall represent different types of users based on the type of equipment. Let us call these instances as User1, User2 etc. Similarly, create a generic class encryption and different types of encryption schemes like AES and DES can be encapsulated in it’s subclasses. Let getData be the function that is used to generate data. applyAlgorithm be the function that’ll apply the encryption algorithm on data. User class can contain encryption class object, so that it can getData and applyAlgorithm of appropriate encryption subclass on it. Wow, we used kind of Strategy pattern (described in one of the previous posts) !

The class diagram looks like-

 

 

Enhancement Required:

Airtel wants to add another encryption algorithm to their encryption schemes. User1 group can now encrypt their data with either AES or RSA. Enhance your software to do the same.

Thought Process:

We can create one more class RSA that is a subclass of Encryption. User1 can use dynamic cast to use either AES or RSA. Simple!

The class diagram looks like-

 

 

 

Wait what!

Yet Another Enhancement:

Airtel wants to provide extra security to certain data packets, and hence they want to add DES algorithm on the top of AES algorithm for User2 group.

Ummm…

We can simply add new algorithms, but considering their demand this type of design may soon lead to an explosion of classes for there can be numerous combination of algorithms that can be implemented (4 combinations for 2 algorithms, 6 combinations for 3 algorithms and so on…)

Modifying the thought process:

The problem is, we are treating AES, DES and RSA as separate algorithms and each time the client wants to use one, we make a subclass encapsulating that algorithm and give the object to the user class.

Instead of this, if we create a getData function in the algorithms class as well, i.e.  in AES class, getData will call getData of User1 and apply AES on the top of it and return data. On this data we can then apply DES by calling DESs getData. In this way each unique algorithm serves as a decorator to the user data. User class will create it’s data packets and then decorate them with any number of encryption algorithms.

Class Diagram looks like:-

 

 

Code looks like:-

class User{

public:

void getData();

};

class User1 : public User{

public:

void getData(){

string *data =createDataPacket(); /*logic to get the data packets from higher layers, add header and necessary information and create data to send*/

return data;

}

};

class Encryption{

protected:

User userInstance;

public:

string* getData();

void applyAlgorithm();

};

class AES: public Encryption{

public:

AES(Data ob){

this.ob = ob;

}

string* applyAlgorithm(string *data){

/*Logic of AES algorithm on data. */

}

string *getData(){

return applyAlgorithm(userInstance.getData());

}

};

int main(){

User1 userInstance1 = new User1();

User2 userInstance2 = new User2();

cout<<userInstance1.getData();

cout<<userInstance2.getData();

AES encryptedData = new AES();

cout<<encryptedData.getData();

}

So, we implemented ‘Decorator Pattern’.

Definition:

Decorator is a design pattern that allows behaviours to be added dynamically to an object without affecting other objects of the class.

Advantage:

1. It is an alternative to sub-classing which can create problems when there are a varied number of behaviours that can be subclassed.
2. It provides the advantage of ‘Single Responsibility Principle’. As defined in wikipedia, it states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function.

Save

Save

Save