Design Pattern – Abstract Factory

Abstract Factories are used to provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Consider an example where we need to create a service for sending data. The data could be sent using various means: by calling a web service, WCF service or by using plain sockets.

To avoid tight coupling the object that sends the data should not be aware of how the data is sent. That’s where abstract factory comes into play. Assuming that all senders implement a  common interface, all the code has to do is call the method that accepts data in whichever format. The benefit of that approach is that we can later easily substitute the protocol for sending data without making any changes to the object that sends data.

In addition, the abstract factory allows the creation of multiple instances of the class responsible for sending data. This is a very useful property when we use dependency injection. The abstract factory can be injected through the constructor and the object responsible for sending data is free to create as many instances of the service as it requires.

That pattern not only solves the coupling problem and separation of concerns, but also allows for better unit testing, since the abstract factory can be very easily mocked.

Advertisements

Design Pattern – Adapter

The purpose of the adapter pattern is actually quite simple. It converts one interface to another one, thus making it possible for classes to work together where the interfaces are different.

Real World Example

Because it’s such a common pattern I had to think for a while before coming up with an example.

Say, our application has to export some data in various formats – excel, pdf etc. It would be quite likely that third party libraries for each of the formats have different interfaces. We could of course write a switch statement, but the better solution would be to wrap each of the third party libraries into a class that implements a common interface. Then all we have to do is resolve the wrapper based on the format. Since the wrapper would implement a common interface the task of exporting data become relatively simple

Dependency Injection to the rescue

Coding Journeyman

code-coupling

I am a developer, I believe in unit testing and I write a lot of them. But it was not always the case, mostly because I was working on a highly coupled code base. Whenever I wanted to test a single functionality I had to set up a lot of things (database, configuration files, …) to do so even if this functionality was not linked to these dependencies. It was spaghetti code into a big ball of mud.

Then I discovered the Dependency Injection (DI) pattern and it changed the way I designed my code and it made testing much easier. The DI purpose is to reduce coupling between software components in order to improve maintainability and testability. I created the following piece of code to demonstrate the principle :

publicclass User
{publicstring Name {get;set;}publicstring Email {get;set;}

View original post 848 more words

Blog at WordPress.com.

Up ↑