If you have already written programs for products or software applications, big / small, you are most likely to have used a lot of Design Patterns… although it is possible they might not be one of the most used / standard design patterns.

But yes, there is an obvious difference between implementing a design pattern and “using” a design pattern… either way, the person working with design patterns understands it, or will understand it easily.

The point is, Design patterns are not new to programmers.

In this below article, I am trying to explain design patterns, in its basics, and we will study details of various patterns, examples, etc. in another article.

What is a Design Pattern?

To Begin…

I think the best way to begin with understanding design patterns, is by understanding non-technical patterns that we knowingly / un-knowingly follow in our everyday lives.

For example, let’s take a lot of Resumes submitted for a job vacancy. Everybody’s resume doesn’t look the same… although they all tend to do the same thing, that is telling a reader what they are skilled at, or how he/she can be a fit for the job.

Majority of them who submit resumes to jobs, know that they need to submit a resume with a particular set of information in a formatted Word document.

This… is a pattern, that everybody submits a resume with a particular set of information expressed in it.

If you feel like… call it Templates instead of Patterns. Design Templates.

There are many such things in real life that are patterns. Some people like the below examples:

All chefs around the globe cook Pizza or French Fries in the same way. Though they may top it / flavor it differently. That is a pattern.

Every car’s design follows a basic design pattern, four wheels, steering wheel, the core drive system like accelerator-break-clutch, etc.

All things repeatedly built / produced, shall inevitably follow a pattern in its design… be it Cars, Pizza, ATM machines, whatever… even ToothBrush.

Designs that have almost become standard way of coding some logic/mechanism/technique in software, hence come to be known as – and hence – studied as, Software Design Patterns.

Why is a Design Pattern Important?

Basically for two reasons:

1. To stick to a standard
2. To fasten the development

I will explain in detail.

Firstly, we see why sticking to a standard pattern is interesting.

Let’s take the list of Resumes example we discussed before.

There might be a one or two applicants who send their job applications by email text without proper formatting, without attachments to their email, etc., .. these one or two applicants are not following the pattern.. and are NOT likely to end up with the job…. why? Because they are deviating from a well established pattern, which might not be liked by the people short-listing resumes for the job.

Isn’t there anybody who deviates from the pattern and becomes “cool”? Isn’t that Innovation?

Yes, there are times that a very differently presented resume gets the job for being different from the others. Usually I have heard of web designers who landed up prime jobs because they compiled and presented a CD movie of their work, or made an animation character explaining their work, had put it up on their blog, and things like that.

But.. this is experimentation (Innovation comes from successful experiments).

Most often in software development, you cannot afford to experiment, because of timeline pressure, expectations, etc., but yes sometimes, some interesting projects do allow for some experimentation.

In software, we cannot do basic things like a Bank Deposit… in 101 ways… there will be just a few ways to process a Bank Deposit.. so makes sense to follow an established and tested Pattern.

Also, most design patterns have variations… some of the variations are so popular that the variations will also be a new standard type of the pattern.

Software projects these days are expected (at least implicitly) to be following an already established design of a similar product / software in the market.

This is where sticking to a standard style of coding or design pattern helps software development… fastening development, removing the overhead of worrying about a new un-tested implementation, etc.,

Fastening development time

Following a standard design pattern also has the advantage of communicating easily through the tree / hierarchy of Software architects, Module leads, Team leads, Developers etc., on “How” something needs to be developed, and not just “What” has to be developed.

Sometimes it even helps Testing Teams, because testers would know by experience that code following a particular design patterns probably could be tested in a specific way with a set of Testing tools in a certain period of time, and such known designs might not have some flaws or have some ‘known’ flaws.

Doesn’t using Design Patterns take out a personal touch?

No. Firstly because we are not saying you follow a design pattern and nothing else happens. Most project implementations only share basic requirements with other projects, and will most likely have deviations. Building these deviations will require flexing and stretching the standard patterns used in an implementation.

It is like making the pizza the standard way, then flavoring it / presenting it to different requirements, either like a full pie pizza, or a cut pie, or whatever.

In understanding the importance of design patterns, one thing is very **important:

Design Patterns are not any technology or framework that a particular company or programming language forces on us. That means, it is like an open concept.. you are free to take it, use it, modify it to your needs, and importantly… feel it your own.

All standard or popular design patterns, actually, are extendable quite heavily.. they became popular, firstly, only because many people use it.. and many people use it only because they are flexible to their requirements.

Or how do you think a standard design pattern would fit a project in New Jersey for a company and also in Bangalore for a different company and a different type of project.

That brings us to “Most design patterns are Generic“… meaning they are not always used for building the same type of software. You might not hear things like “Banking software design pattern” or “social networking software design pattern” used in common discussions… but only “Design Patterns”.

Who Should be Bothered about Design Patterns?

1. Just like how a good building Architect grows his skills of designing buildings, by studying the Architecture and Design of numerous buildings and shapes throughout his/her life, a Software Architect should study and visualize how different Software / Technology systems across the globe are designed or architected.
2. And just like how the construction workers of a building should be aware of different ways of implementing a building design, either from their own experience or by understanding it from the Building’s Architect.

Software developers/programmers should understand basic software design patterns and their implementation code… either themselves or from the Software Architect who instructs the team to develop it following a particular Pattern.

Basic Code Patterns

In the opening lines of this article, I said any programmer would have used design patterns. Here are some very basic examples of code following a pattern.

1. Following is a basic Intercepting Filter design pattern.
2. Hide Copy Code

3. switch (condition){
        case Value1:
        case Value2:
        default:
   }
   

4. Event triggers, Event Handlers.. come under basic Subject-Observer design pattern. We will discuss each patterns standards, popular variations, with examples.. soon.
5. If you have used some kind of collections, like Arraylist in C#, and iterate through the array, then you have used a basic Iterator design pattern.
6. The below code is an example of a basic Exception handling / Chain of Responsibility pattern.
7. Hide Copy Code

8. try{
   }catch(Exception ex){
   }
   finally{
   }
   

Different Areas of Design Patterns

There are different terminologies in software other than Design Patterns.. some of them often related to Design patterns that we have so far discussed.. and some of them entirely unrelated.

What we have so far discussed above is sometimes called “Implementation Design Patterns“.

There are others, like Architecture Patterns, Framework Patterns, Language Patterns (mostly called Language Constructs).

They are patterns laid at different levels… like Language patterns are patterns implemented as part of programming languages like C# / Java, as the language’s features / constructs.. some of them we have seen already.

All above examples of subject-observer, intercepting filter, etc., are absorbed as language constructs in all popular high-level programming languages which came after C.

Architecture patterns are those standard models of software architecture, commonly referring to different methods of placing or linking modules or layers or tiers, making up the full application.

This is entirely unrelated to design patterns in the sense of coding/programming that… but they share the same answers to Why’s / What’s as discussed in this article.

Framework patterns are also unrelated to our discussion of design patterns. When frameworks like .NET implement special means for Logging errors or Tracing code execution routes easily through the framework’s in-built methods or objects, such mechanisms are referred as Framework patterns.

Some examples in the .NET Framework include the stackTrace feature, the class attribute feature with [] square braces on top of class/method definitions, etc., When using such features, we are coding with the Framework’ in-built patterns.

I hope this article helps provide an Overview of Design Patterns and related terminologies.

So far, we only discussed what the standards are and how important they are.. but we didn’t discuss what the standard patterns itself are.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL).