Design Patterns after few years – Adapter, Factory Method, Factory

If you have some technology (ADO.NET/NHibernate/WCF/etc.. ) related components in your project and you wish to decouple other layer from that but many, many lines, APIs exist in whole product, there is the super pattern for you. Yes, it is simple and well-known pattern with simple name – Adapter.

You can encapsulate existing APIs in a small adapter with composition and interfaces – this great mechanism can improve many of old code bases which are difficult in managing or reading, etc.

Example:
You have DataRow class (or own class) dependency in your component. Or maybe in other words, you have class which doesn’t have virtual members – you cannot make a mock from this class. Of course you can use some ultra mocking framework (for example TypeMock library, of course it costs $$). On the other hand, you can create simple adapter with interface, make your component dependent from interface of adapter instead of DataRow class or similar, then in Adapter class you create dependency from mentioned technology and … everyone is happy!

Simple things:

  • interfaces
  • composition & delegation
  • adapter pattern

used by developer during software creation and then, product becomes an improved product. Additionally, creating unit test for a class with mocked dependencies is possible now! Moreover, if you want to follow the SRP way (single responsibility pattern), now it is really easier!

The factory pattern, the factory method pattern … Using new keyword in other places than mentioned patterns is bad thing. After few years, if you try this idea you will be sure, that it is right way. Below there is simple example:

public interface IMySimpleComponent
{
	bool SomeAction();
	string SomeProperty { get; set; }
}

public class MySimpleComponent : IMySimpleComponent
{
	private MySimpleComponent()
	{
		this.SomeProperty = "init_value";
	}

	public bool SomeAction()
	{
		// some action code...
	}

	public string SomeProperty { get; set; }

	public static IMySimpleComponent CreateIt()
	{
		return new MySimpleComponent();
	}
}

Additionally thing to remember, if you do not have any really good reason to make a class, interface, enum or struct as a public, leave it as an internal. It will save you a lot of time when you will work with big project.

In our example, we make class a public, because we want to have an access to factory method from outside, but you can create public factory which will be accessible by everyone and then you can change a MySimpleComponent class to be an internal class.

Maybe not discovery of the year but I am sure, these things are worth remembering.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s