Adapter Design Pattern
The Adapter Design Pattern is a structural pattern that allows objects with
incompatible interfaces to work together. It acts as a bridge between two
incompatible interfaces.
This pattern is useful when you want to use existing classes, but their interfaces
do not match the one you need.
How can we make these two incompatible systems work together?
We need to introduce an Adapter between the HR and Third Party Billing systems, as
shown in the image below.
Adapter Design Pattern in C# can be implemented in two ways.
1. Object Adapter Pattern
2. Class Adapter Pattern
Implementation of Object Adapter Design Pattern in C#:
Step 1: Creating Employee Class
Step2: Creating Adaptee
Step3: Creating ITarget interface
Step4: Create an Adapter
Step5: Client
Class Adapter Design Pattern in C#:
This is another approach to implementing the Adapter Design Pattern in C#. In this
approach, the Adapter calls will implement the ITarget interface and inherit from the
Adaptee class. That means the Adapter class will now be a child of the Adaptee class. So,
instead of creating a reference variable of Adaptee to call the Adaptee method, it can call
that method directly as it is available via inheritance. Before implementing the same
example using the Class Adapter Design Pattern, let us first understand the class
diagram of the Class Adapter Design Pattern. Please have a look at the following image.
Facade Design Pattern in C#?
Facade Design Pattern states that you need to provide a unified interface to a set of
interfaces in a subsystem. The Facade Design Pattern defines a higher-level interface that
makes the subsystem easier to use.
The Facade Design Pattern is a structural pattern that provides a simplified interface to a
complex system of classes, libraries, or frameworks. The primary goal of the Facade
pattern is to present a clear, simplified, and minimized interface to the external clients
while delegating all the complex underlying operations to the appropriate classes within
the system. The Facade (usually a wrapper) class sits on the top of a group of
subsystems and allows them to communicate in a unified manner.
As the name suggests, Facade means the Face of the Building. Suppose you created one
building. The people walking outside the building can only see the walls and glass of the
Building. The People do not know anything about the wiring, the pipes, the interiors, and
other complexities inside the building. That means the Facade hides all the complexities
of the building and displays a friendly face to people walking outside the building.
Understanding Facade Design Pattern in C# with one Real-Time Example:
Identify Complex Subsystems: First, identify the complex parts of your system
that need simplification. These could be complex libraries or systems with
multiple interacting classes.
Create a Facade Class: Design a facade class that provides a simple interface
to the complex subsystems.
Delegate Calls to Subsystems: The facade should delegate the client requests
to the appropriate objects within the subsystem. The facade should handle all the
intricacies and dependencies of the subsystems.
Client Code Interaction: The client interacts with the system through the
facade, simplifying its use of the complex subsystems.
As shown in the above image, to place an order first, the Client needs to create an object
of the Product class and get the product details by calling the GetProductDetails method.
Then, if everything is fine (i.e. if the Product is available in stock), you need to make the
Payment. To do this, the Client needs to create an instance of the Payment class and
need to call the MakePayment method. If Payment is successful, then we need to send
the Invoice to the customer and to do so, the Client needs to create an instance of the
Invoice class and call the SendInvoice method. So, to place the order, the Client needs to
do the above-mentioned steps in a particular order.
The Facade Design Pattern in C# is actually an extra class (i.e., a Wrapper class or, you
can say, Facade Class) that sits at the top of the above classes. Please have a look at the
following diagram for a better understanding.
So, here, the extra class Order is nothing but the Facade class, which will be responsible
for placing the order. This class internally creates the instance of the respective classes
and calls the methods in a particular order. Now, the Client will not call the respective
classes and their methods to place the order; instead, the Client will call the Order Class,
PlaceOrder to method to place an order. The PlaceOrder method will internally use the
Product, Payment, and Invoice classes to place the order.
Note: The point that you need to remember is the Facade Design Pattern not only
decreases the overall complexity of the application but also helps to move the unwanted
dependencies to one place. Facade deals with interfaces, not implementation. The actual
implementation is going to be provided by the Subsystems.
As shown in the above image, three classes are involved in the Facade Design Pattern.
They are as follows:
1. The Facade Class knows which subsystem classes are responsible for a given
request, and then it delegates the client requests to appropriate subsystem
objects.
2. The Subsystem Classes implement their respective functionalities assigned to
them, and these Subsystem Classes do not know the Facade class.
3. The Client Class uses the Façade Class to access the subsystems.
Implementing Facade Design Pattern in C#:
Step 1: Creating Subsystems
Product Subsystem:
Payment Subsystem:
Invoice Subsystem:
Step 2: Creating the Facade Class
Step 3: Client
Advantages of Facade Design Pattern:
Simplified Interface: Offers a single, simplified interface to the complex
subsystems, making the subsystems easier to use.
Reduced Complexity: Clients interact with a single unified interface rather than
directly with the complex subsystems, reducing the system’s perceived
complexity.
Isolation: Provides a degree of isolation from the complex subsystems, which can
be beneficial when there are frequent subsystem changes.
Improved Testability and Maintainability: Facade can simplify the testing process
by limiting the interdependencies and focusing on system interfaces.
When to use Facade Design Patterns in Real-Time Applications?
The Facade Design Pattern is particularly beneficial in the following scenarios:
Simplifying Complex Systems: When dealing with a complex system or framework
with multiple interdependent classes or layers, you want to provide a simple
interface to these systems. The Facade pattern can encapsulate this complexity
behind a simple, unified interface.
Decoupling Systems: If you want to decouple a system where the components are
tightly coupled or interdependent, a facade can provide loose coupling by not
exposing the internal complexities to the client.
Layered Architecture: A facade can act as an entry point to each layer in multi-
layered architecture. This is particularly useful in large applications or systems
where each layer has complexities.
Improved Readability and Usability: When you aim to improve the readability and
usability of a system. A facade can provide a clear and straightforward way to
interact with a complex subsystem, making it easier for other developers to
understand and use it.
Reducing Dependencies: To reduce external code dependencies on the inner
workings of a library or framework, thereby shielding the client code from future
changes or complexities in the subsystem.
Subsystem Interface Standardization: For standardizing the interfaces of
subsystems. If different subsystems have different interfaces, a facade can
provide a uniform interface to all these subsystems, making them easier to work
with.
Example without using Facade Design Pattern in C#:
Let us first implement the Customer Registration Application without following the Facade
Design Pattern. In this example, we are going to use the Customer class to store the
customer data along with one class called Validator to validate the customer data, one
class called CustomerDataAccessLayer to save the customer data in the database, and
one class called Email to send the successful registration email to the customer.
Using the above Classes in Client Code:
Now, we need to use the above classes in the client to provide the customer registration
functionality. The Client should and must use the above classes and methods in the
following order.
1. First, create an instance of the Customer class, then populate the properties with
the required data
2. Next, we need to create an instance of the Validator class and need to call the
ValidateCustomer method by passing the customer object to validate the
customer data.
3. Once the customer is validated, then the client should create an instance of the
CustomerDataAccessLayer class and must call the SaveCustomer method to save
the data into the database.
4. Once the data is saved successfully in the database, then the client needs to
create an instance of the Email class and needs to call the SendRegistrationEmail
method to send the registration successful confirmation email to the customer.
What is the Problem with the above Design?
Now, if you see the output, then you will see the output as expected. Then what is the
problem with the above application design?
The problem is now we have many subsystems like Validator, CustomerDataAccessLayer,
and Email.
And the Client needs to follow the appropriate sequence to create and consume the
objects of the above subsystems.
And here, there is a high chance that the client might not follow the proper sequence, or
the client might forget to use one of the subsystems. For example, in the below code, the
client forgot to use the Validator class and hence there is a chance that we might save
some invalid data in the database.
How we can overcome these problems?
Instead of providing access to these subsystems, if we create a simple interface and give
access to the client and the client will use the simple interface to do the registration. The
complex logic will be written inside the simple interface. And we can achieve this very
easily by using the Facade Design Pattern in C#.
The Facade Design Pattern will hide all the complexity and provide an easy-to-use
interface to the client and the client will use the Facade instead of the subsystems. So,
with Facade Design Pattern, our class diagram or UML diagram will look like the one
below.
Template Method Design Pattern in C#