Structural Design Pattern (Part 2)

Previously, I had published/written a blog post on Design Pattern presentation wherein I gave away a link to my slideshare PPT about this topic. I am glad to say that many people liked the PPT and have requested to write-up in detail about the same PPT. Please go through my first post if you have not done so.

Note: Let me warn you that these couple of posts that I am going to write will be lengthy ones, so read it if you have time.

Ok then amigo, let's start.

In this article, I shall be talking mainly about few Structural Design patterns as it is in the slides. Now if you are referring to the PPT, then I have picked 4 structural patterns, viz. Adapter, Bridge, Decorator and Facade. Of course, they are not the best but not the simplest either , so in this article, I shall try to recall and explain to my best capabilities the same way as I did while giving this presentation to my team months ago.

Let me start off by saying that Design Patterns are not the answer for every problem, but rather the solution to specific problems. In other words, normally I have seen developers who start off by learning Design patterns happen to get crazy/obsessed over it and thus start to use it extensively in their production code. Hey, you’re not alone buddy, even I was the same.

Although patterns do help us a great deal, they still have their downsides too. Many experts argue that design patterns are a big drawback or failure in software programming as it induces many problems. Well, I won't be talking about it in this post nor am I an expert. So it is recommended not to extensively make use of Patterns wherever you see a code smell. If there is a simple flexible solution, then it is suggested to use that rather than patterns. I remember once my ex-colleague was saying that too much use of patterns is like putting yourself into haywire condition or even perhaps hanging yourself.

Well then, we know that Design patterns are broadly categorized into 3 parts, viz, Structural, Behavioral and Recreational. Since this article is only with respect to Structural, I am going to stick with it.

Let me get into details about this category and 4 patterns I have picked to talk about. I shall explain as to how I always question myself in learning a topic. Hope you will like it. Basically, I shall ask myself four basic questions: What, Why, How and Where.

Structural Patterns

What

This pattern category shall talk about or defines the composition between the modules or components or even entities which allow us to develop or build great larger systems. As the name says, it defines how each component or entity should be structured so as to have very flexible interconnecting modules which can co-work together in a larger system.

Many a times, it so happens that fitting modules or components in a system which may be new or an existing one seems like a tedious job. Or even at times wherein many different components have to co-work together in a well mannered way to achieve the final structure.

Why

This patterns allows us to build or develop a module and fit them appropriately or even make them work coherently and comfortably among other modules which further helps in understanding relationships between objects and classes. Without this category of patterns, one would have to change a lot of stuff around to fit in a module. Hence to avoid this re-work or clumsy work around, this pattern is used.

Let me show you my visualized image of an complex system as per the image below:

As you can see form the above image, if I assume those are the objects/modules which are quite different in their own nature due to its behavior and responsibilities given to it. Now looking at the above picture, it's pretty sure that nothing is organized properly. That means that the structure of the whole complex system is very messy.

If you want to add a new object type (a round shaped object perhaps?) or a module into this system and build up a communication with others, imagine how difficult it is. Not only is it a very tedious job, you either will create more objects/modules to accommodate this new object/module or you will modify existing objects to fit the new one, thus you might break some things, which involves testing every test case on the system to check its consistency.

So upon using this Structural pattern, you can change the structure of the system to something like shown below:

As you can see from the above image, I have applied many different structural patterns to organize the structure in more of a logical group. Now this way, you can easily analyze the structure of the system as well as its communication aspect too. Now changing/adding anything to this more organized structure is not that difficult a job.

Note: The above representation image is just for the sake of understanding. This is in no way any UML or similar representation.

How

As said earlier, I have picked the following patterns among a lot more:

1. Adapter
2. Decorator
3. Bridge
4. Facade

Where

This depends on each of the patterns which fall under this category, so please read each one of those in my blog posts.

Let me end this Part 2 article here itself, so that it won't be a very long one which might bore you off. Please look forward to Parts 3, 4, and 5 or even more - it really depends on how long each post goes.

Thanks for reading.

P.S.: Your valuable comments for my learning are well appreciated.

Filed under: C#, CodeProject, dotnet
Tagged: .NET, blog, C#, codeproject, dotnet, tips