[C# Design Patterns] The Wrapper/Facade Pattern

What it is the wrapper/facade pattern?

A wrapper, or facade, is when you create a new class, in order to hide how another class (or group of classes) works.

 

If you’d like to see this as a video, watch it here:

 

Why would you use a wrapper/facade?

There are two main reasons why you would use a wrapper.

The first is when you have a class, or a group of classes, that are complex to work with. For example, if you want to send an e-mail. In order to send an e-mail from a C# program, you need to create an e-mail message object, possibly create multiple objects for the e-mail addresses, and create an e-mail server object. Then, you can finally send out the e-mail. You also need to remember to include two “using” statements for namespaces that are rarely used.

That’s a lot of objects to create, in a specific order, just to send out an e-mail. It would be nice if you could create a single, simpler object that will hide all that complexity.

The second reason, which is less common, is to hide the implementation of third-party libraries – especially if they might change over time. Many libraries are updated at least once a year. And, occasionally, an update has a change that breaks your existing code.

If you have wrapper classes, that don’t do anything other than inherit from the library’s classes, you might be able to make one change in the wrapper class, in order to make the updated library work the way you want it to work.

 

Code Samples

For this demonstration, I’ll create a wrapper class in C# that sends an e-mail.

 

Simple version, without a wrapper/facade

If you’re sending a simple e-mail – only one “to” recipient – the code can be fairly simple, like this:

After you create the MailMessage, there is a little configuration that needs to be done for the mail server (SmtpClient). You also need to remember to include “using” statements for “System.Net” and “System.Net.Mail”.

 

More complex version, without a wrapper/facade

If you want to send an e-mail to multiple recipients (or CC and BCC recipients), the code gets noticeably longer. Plus, you need to use three different types of objects – MailMessage, several MailAddress objects, and the SmtpClient. It takes 36 lines of code to send out this sample e-mail.

 

Slightly simpler version, still without a wrapper/facade

You could simplify the previous code by instantiating the MailAddress objects in-line. That will make the code a little shorter (it’s down to 26 lines now). But, there is still a lot of work that needs to be done (this code still needs to use three different classes, and have the mail “using” statements added), to send out an e-mail.

 

Simplest version, using a wrapper/facade

By building a wrapper, I’ve reduced the previous code to 7 lines. These lines don’t need to create any objects, and you don’t need to include the mail-related “using” statements.

Here’s what the code looks like now:

 

For this wrapper/facade, I created a class that uses a fluent interface. Your wrapper classes don’t need to use a fluent interface. It’s just the technique I chose to simplify this code.

This fluent interface could be improved; it doesn’t force any “grammar rules”. But, it’s good enough to show how a wrapper/facade works. This will show you how to create a powerful fluent interface.

For this wrapper, the EmailCreator class handles building all the objects needed to send out an e-mail. The interface (IEmailFluentInterface.cs) is needed to make EmailCreator into a class with a fluent interface.

EmailCreator.cs

IEmailFluentInterface.cs

With a wrapper like EmailCreator, you can easily send out e-mails from any place in your programs. You’ll also be ready if the mail objects (MailMessage, MailAddress, and SmtpClient) ever change how they work.

 

Where I’ve found it useful

I actually encountered the e-mail message problem in a program I worked on several years ago. The .NET 2.0 framework changed the way they handled e-mail addresses, compared to how it worked in .NET 1.1.

I’ve also seen a large system that used a third-party UI control library. After several years without updating the library, the company decided to finally move to the latest version. It took several programmers, many days, to update the UI code to the new version. Once they were “done”, they still encountered problems over the next few weeks.

If we were using a wrapper, or facade, it would have been easier for us to handle those changes.

 

Additional Resources

Build your own fluent interface: https://scottlilly.com/how-to-create-a-fluent-interface-in-c/

3 thoughts on “[C# Design Patterns] The Wrapper/Facade Pattern

  1. Hello Scott – thank you for taking the time to create these well-done articles.

    I’ve a question that is not necessarily about the Wrapper pattern but is somewhat linked.

    I’m writing a program that will convert objects from one class to another and I want to make it easy to see all of the property mappings, i.e. what property in the sourceclass maps to a given property in the destination class. Not all the properties would map though, some properties in the destination class would need to be computed.

    I created a dictionary that holds the mappings, like so –

    Dictionary<string, string> PropertyMapper; with the key being the destination property name and the value being the source property name.

    The code would look something like this –

    Here, ItemSKU is the propertyname in the DestItemClass.

    While this would make it easy to handle propertyname updates in the source class, a class that I consume and is provided by a thirdparty, does this approach make sense?

    Is there a better way to handle mapping of properties between objects?

    Thanks.

    1. Hello Rakesh,

      If it fits your program’s needs, I would consider using the AutoMapper library. It is very robust, and handles many complex situations – such as, when a class has a property that is another class, or is a list of other business objects. It also includes the ability to do validation of the conversion, in case the third-party objects have a new structure.

      If that won’t work for your situation, please tell me. I started to write a library to map between C# objects and SQL tables. I stopped when it needed to handle List properties (when it became very complex). That library might have some ideas, if AutoMapper will not work for you.

Leave a Reply

Your email address will not be published. Required fields are marked *