In a previous article, I provided an overview of Design Patterns and related terms... apart from promising another article (which is this) to explain the standard design patterns with example scenarios and code.
Note: The rest of this article will explain with examples some of the standard Implementation Design Patterns, from a developer's perspective. And the examples will be in C# code... and I believe readers from VB / Java / PHP or other programming languages can relate to the examples (please feel free to contact me if you want translated code in your favorite language to be added to this article).
Introduction
Design Patterns (or Implementation Design Patterns to be specific), in the initial stages, was just a set of popular code blocks often communicated between developers or Application designers without specific coined terms.
That is the time when four people authored a book on these popular often-used code blocks of implementation design, and made the term / coined word "Design Patterns" popular. These people come to be referred to as Gang Of Four.
The point of telling that History again, which most possibly you have already read / heard a 100 times, is that, the patterns we discuss in this article are going to be from the Gang Of Four list of Design Patterns.
Over the years, many more design patterns have become popular, either new ones or variations to the published standard patterns referred in the book by the four people. In other words, this article is not going to be able to discuss a complete list of design patterns.
Getting to Know Design Patterns
Almost all patterns basically can be considered good examples of Object Oriented Programming... that means implementing design patterns requires good knowledge/experience with OOPs.
Interfaces & Classes
In OOP we have learnt that Classes can implement Interfaces... and that it is best for classes to do so because the Interface then provides the structure / methods that the Class should implement in its code, like a rule book.
So developers of the Class don't miss something, and creators of the Interface have a structured mechanism to make Class developers adhere to rules.
And these rules / interfaces can then become a common rule which many Classes implement in the same library or application.
The same with having abstract classes defining an abstraction, for a class to then inherit and apply.
Most Design Patterns will use Interfaces, Abstract Classes and Classes to implement Abstraction, Separation, and Rules. We will see more of it.
An Implementation Pattern
An example:
interface ITelephone
{
void MakeCall(string PhoneNumber);
void Receivecall();
}
class Phone : ITelephone
{
public void MakeCall(string PhoneNumber)
{
}
public void Receivecall()
{
}
}
In the above example, the ITelephone interface defines a rule.. which the implementation class Phone uses.
Now, going below the surface, the real advantage of building classes & interfaces come to play only when we have much more of them... like below:
public interface ITelephone
{
void MakeCall(string PhoneNumber);
void Receivecall();
}
public interface ISMSDevice
{
void SendSms(string PhoneNumber, string Message);
void ReceiveSms();
}
public interface IMobileDevice
{
void SetDateTime();
void ChangeTimeZone();
void SetReminderAlert();
void GetContacts();
void AddContact();
}
class Phone : ITelephone
{
public void MakeCall(string PhoneNumber)
{
}
public void Receivecall()
{
}
}
class MobilePhone : ITelephone, ISMSDevice
{
public void MakeCall(string PhoneNumber)
{
}
public void Receivecall()
{
}
public void SendSms(string PhoneNumber, string Message)
{
}
public void ReceiveSms()
{
}
}
The above code shows how interfaces can define different rules while classes implement them.
The rules (given by interfaces) and the creation process (given by classes) are isolated... so that the same Creation process can be used to create various representations of the object.. like a Phone and a Mobile Phone both implementing the core features of a Telephone.
The above code implementation is called a Builder Pattern... because it lays down a pattern for making building blocks.
Using the Builder Pattern
public class PhoneServices
{
public void CallNumber(ITelephone Device)
{
Device.MakeCall("9278349082");
}
}
class Myclass
{
public void RingAContact()
{
PhoneServices ph1 = new PhoneServices();
ITelephone phone = new MobilePhone();
ph1.CallNumber(phone);
}
}
- A
PhoneServices class, implements logic, to do operations (like CallNumber()) on different objects (Phone or MobilePhone instances which are both ITelephone Devices) with the same code, because the objects implement common interfaces (ITelephone).
I will call the PhoneServices class a “Usage” class, because it doesn't implement the design but only uses it. So that a Client Class (which I will call as “Create & Use” class), MyClass, can create instances of a Phone / Mobile Phone and call the CallNumber() method. - If a need arises later to make a new type of Phone like the PDA, then relevant new interface and implementation can be developed... and the PDA class can implement both existing and new interfaces without necessarily modifying existing code.
Isn't it easier to code simply without much interfaces / classes, so you don't have to bother about maintaining all of that ?
The idea of builder pattern, or any other design pattern is the idea of OOP itself.
It is similar to isolating the Human Body into skeleton and muscle... so that it helps separate Development teams take care of each block of implementation, like making the skeleton (An Interface), separated from wrapping the muscle (A Class) around it... so the muscle team doesn't have to understand everything about the structure of the human body, but they have to just follow the connection points (Interface Definition) in the skeleton and add the muscle.
In other ways, the skeleton (Interface) team wouldn't bother what implementation (Class) the muscle team does... it only states the mandatory structures (Interface Definition) required.
Object Oriented Programming
When we are making something so complex as the Human Body, we can't expect everything to be understood by every person on a Team. Right from the requirements, to design, to the implementation and testing, things have to be split.
The development has to be modularized (as Objects), to keep things tight and isolate people's tasks, to allow them to focus on every bit and inch of what is being developed.
There can further be a blood vessels team, a nerves team, etc., who, then, bother only about the design of things in their scope.. so that, finally a Creator team, can implement code, which uses instances of all these design blocks, to make the full human body. The Creator team technically acts like the user of all the Building blocks.
An Adaptation
Let us make some crude but interesting real life scenario assumptions.
Assume that we rolled out a product which contains our builder pattern example code... and lot of companies bought the product and implemented it into real phone and mobile devices to allow the device to make calls, receive calls, send SMS, etc.
Now we have been requested by a laptop manufacturer to provide software to allow a laptop to provide phone services through one of its in-built hardware... but the laptop's hardware provides different communication ports or mechanisms different from a phone or a mobile device. We want to adapt our library to be useful here, at the same time not change any existing code because we sell the same telephone library already to phone companies.
What we would then do is .. typically make an adapter class... which will convert phone calls to laptop based communication... as below.
public class Laptop
{
public void OpenVoiceSocket()
{
}
public void SendVoiceData()
{
}
}
public class LaptopAdaptor : ITelephone
{
private Laptop computer1 = new Laptop();
public void MakeCall(string number)
{
computer1.OpenVoiceSocket();
computer1.SendVoiceData();
}
public void Receivecall()
{
}
}
As you see above, the two classes can be part of entirely different libraries which are released by different companies, one by you (LaptopAdaptor), and another by the Laptop company.
The Adaptation is done in the LaptopAdaptor class which shall go into our phone library as a new class without disturbing existing code. The LaptopAdaptor class converts Phone operations into Laptop communication operations by calling Laptop communication methods.
This is called an Adapter Pattern.
Splitting up Implementation and Adding Bridges
Now, let us change some of our old code in a different way. If we change our earlier phone example to something like below.... keeping the ITelephone and ISmsDevice interfaces, and rewriting everything else.
public class GenericPhone : ITelephone
{
public void MakeCall(string PhoneNumber)
{
}
public void Receivecall()
{
}
}
public class GenericSMS : ISMSDevice
{
public void SendSms(string PhoneNumber, string Message)
{
}
public void ReceiveSms()
{
}
}
public interface IPhone
{
void MakePhoneCall(string PhoneNumber);
void SendMessage(string PhoneNumber, string Message);
}
public class MobilePhone : IPhone
{
private GenericPhone phone;
private GenericSMS smsDevice;
public MobilePhone(GenericPhone DeviceHandle1, GenericSMS DeviceHandle2)
{
this.phone = DeviceHandle1;
this.smsDevice = DeviceHandle2;
}
public void MakePhoneCall(string PhoneNumber)
{
phone.MakeCall(PhoneNumber);
}
public void SendMessage(string PhoneNumber, string Message)
{
smsDevice.SendSms(PhoneNumber, Message);
}
}
static void MakePhoneCall()
{
IPhone userPhone = new MobilePhone(new GenericPhone(), new GenericSMS());
userPhone.MakePhoneCall("234234");
}
We arrive at a different implementation. In the Builder Pattern, we kept all implementation logic inside the Phone and MobilePhone classes... and actually the implementation for MakeCall and ReceiveCall are repetitive. That repetition is ok for some designs.
To avoid repetition and manage changes easily at one place, we can split implementation into multiple layers, like in this code above... which shows how it helps put MakeCall() implementation in one place. But, this is needed only if the project is big and has lot of operations to be made abstract. On small projects, too many layers of abstraction will make the code complex and heavy on maintenance.
The above code separates some amount of implementation (example: MakeCall, SendSms methods), into another set of classes (GenericPhone and GenericSmsDevice). This demonstrates not just separation of design rules and implementation, but separates the implementation part into a core implementation and operations implementation.
Now the operational code (example: MobilePhone) are delinked from the implementation code (example: GenericPhone)... and finally kind of making a bridge between the operations and the implementation, the above code makes for an example of the Bridge Pattern.
The main advantage of Bridge Pattern over Builder Pattern is it isolates changes to core implementation from affecting the operational code (the bridge classes).
Some day, if the implementation to making a phone call changes, or has some additional work to be done like formatting the phone numbers before making the call, to fix a bug, then the bridge classes need not be touched.. only the core implementation classes need to undergo modifications and testing.
Making a Mediator
Suppose we have a scenario, that our company also had a team which developed a fax messaging library, and an emailing library.. and we want to bring them together, to finally make a full communications system.
And say that different messages can come to the same processing module in the communications block implementation, which then processes / sends the messages appropriately, based on whether it is an email request or an SMS request or a fax request.
Then we can call the central block of code that handles this as a Mediator... and the entire system to be having a Mediator pattern... the other blocks like phone module, the fax module could be developed in different patterns.
Enough of scenario assumption.. it is something like the below code, assuming FaxDevice is a class implementation in another referenced library in the project
public class Communicator
{
public void SendMessage(string Message, string PhoneNumber, string Mode)
{
switch (Mode.ToUpper())
{
case "FAX":
FaxDevice faxer1 = new FaxDevice();
faxer1.SendFax(Message, PhoneNumber);
break;
case "SMS":
MobilePhone phone1 = new MobilePhone();
phone1.SendMessage(PhoneNumber, Message);
}
}
}
Communicator commChannel = new Communicator();
commChannel.SendMessage("Fire in Deck 01A! ", "+11232342323452", "EMAIL");
The above usage code can be part of some module or library which has no idea of existence of a MobilePhone class or a FaxDevice class... but still can send messages on the devices through the Mediator.
Mediator patterns are most useful in integrating two or more systems, or blocks of implementation (B1, B2, … Bn) which are independent of each other, and can't allow calling each other or be aware of each other.
Examples are like integrating with a 3rd party library, or co-ordinating legacy systems with new system code, etc.
Confused with Different Patterns?
How to remember which pattern should be implemented with an interface and which with an abstract class?
Did you notice that I have used a switch statement in the above example to implement the Mediator pattern? Does that makes it more an Intercepting Filter pattern than a mediator Pattern?
Well, this is the part I love about Design Patterns...
Any Design Pattern you implement could possibly have other patterns inside it.. like you can implement Mediator pattern using a Bridge, or use an Adapter to implement a Bridge, etc.
It all depends on your code.. there is no rule that Builder patterns should use Interfaces (you can use abstract classes in place of the interfaces), and no rule that you should not use an Intercepting Filter to implement your Mediator.
It will not be interesting to implement a pattern using the same kind of code you find in this article or elsewhere... but it will be interesting when you understand that a mediator pattern it becomes, when you write a separate layer to mediate between two independent blocks... and a bridge pattern it becomes when you separate operational code (or Operations calls to do work) from actual implementation (the actual implementation code) with abstractions on either side... like that.
I am going to leave it here with patterns and examples, but there are more design patterns both in the Gang of Four book and outside of it in the software community.
Different Pattern Categories
There is one other thing we didn't discuss so far. They are Pattern Categories.
Generally, Patterns are categorized into three buckets.. Creational, Structural and Behavioral Patterns.
We have discussed the Builder Pattern which is a Creational pattern, because of its logic being more interested in setting creational rules for Building blocks without separating stuff into layers.
We have discussed the Adapter Pattern and Bridge Pattern, which come under Structural Patterns, because they separate stuff into layers thereby adding a structure to different classes sharing the implementation.
We have discussed the Mediator Pattern which is a Behavioral pattern, because it gives more importance towards implementing the mediating behavior for a class.
Conclusion
There are many more patterns which are further put into the different categories for making it a little easier to decide when to use which kind of pattern.
But, there will be code that implements a structural design pattern, seemingly using a behavioral pattern, and the like. Mixing and matching the patterns to implement requirements is most often a necessity.
This article misses a lot of graphical representation, using UML and block diagrams, which could have made it more clearer and beautiful to visualize... I will try to add them soon. Meanwhile you can use some the below interesting reference links for further clarity.
I hope this article was useful.. please leave your comments, thoughts and feedback.
Reference Links
History
- 17th November, 2010: Initial post
