Design Patterns and why they matter. Chapter 1

If you are reading this post I am pretty sure of two things:

  • You have heard about Design Patterns before and someone told you that they are cool.
  • You want to improve your coding skills.

This series of post will introduce the reader to Design Patterns and the reasons behind their usage in the day-to-day work as front-end/fullstack developers.

I have been working for years using Design Patterns in some different languages (Java, Ruby and Javascript) and in all these years I have answered the same questions for people that were not aware about how to use them.

These posts will show up a conversation between two colleagues where the most important ideas will be answered. Our players will be two front-end developers, Rita and Sophie.

  • Rita doesn’t know too much about Design Patterns.
  • Sophie has been using Design Patterns for a long time.

 

Rita: Hi, Sophie! I’ve heard you know what Design Patterns are and why they are important to use. Could you explain to me what the Design Patterns are? Do I need some knowledge before getting into Design Patterns?

Sophie: Hi, Rita! Yes, I have been using Design Patterns in mostly all my projects. For starters, maybe the best way to describe what a Design Pattern is to read what Wikipedia says about it:

“…a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design…”

But what does it mean? Well, in my experience a Design Pattern is a recipe that has been proved to be useful solving a specific problem in a specific context.

Think of them as a kind of helping template more than a complete solution to your problems.

There’s some extra benefits you will freely get by learning Design Patterns: you will improve your code structure, but you’ll communicate with your peers in a much better way too.

Only minimum OOP experience is required to understand Design Patterns better.

Rita: Umm! Now I have more questions popping into my head!  What does ‘have been proved’ mean?  Do I need to learn Java or other compiled languages before using Design Patterns?

Sophie: It means that all these Design Patterns have been used by the community in different projects and that they have solved the problem. Design Patterns are language agnostic, they are not tied to any language, so you are free to implement it in the language you are more efficient and adapt them to get the most out of the language and the most out of the Design Pattern.  Even you will be able to see how some patterns raise up only in specific languages.

Rita: So, can I use any Design Pattern to solve my problems?

Sophie: Not really, the keyword here is ‘specific’. Not every Design Pattern is suitable to solve all of your problems and not every problem can be solved with Design Patterns. Sometimes you will need one Design Pattern to solve your issue, sometimes you will need to use more than one and sometimes you will realize that solving your issue is not possible using any of the Design Patterns, but in my experience this situation rarely happens.

Rita: Ok. How many Design Patterns are there?

Sophie: Design Patterns are categorised into different categories depending on the problem that they are supposed to solve.

  • Creational patterns
    • These are designs that deal with object creation mechanisms and that try to create objects in a manner suitable to the situation. (wikipedia)
  • Structural patterns
    • These are designs that ease the design by identifying a simple way to realize relationships between entities. (wikipedia)
  • Behavioural patterns
    • These are designs that identify common communication patterns between objects and realize these patterns, so using them increases flexibility in carrying out this communication (wikipedia)
  • Concurrency patterns
    • These are designs that deal with the multi-threaded programming paradigm. (wikipedia)

Rita: Wow! And do I need to know all of them?

Sophie: Don’t be afraid, Rita! If you want I can briefly introduce you to those design patterns that you will be able to use in your daily work. I’m pretty sure you already use some of them, so now all you need is to learn how to recognise them!

Rita: Cool! It sounds quite much relieving.

Sophie: As a Javascript developer you are aware of polluting globals and what the collateral problems are, right?

Rita: Of course! Leading with 3rd party libraries and with your own code could be really messy if you are not aware of it. jQuery API has the ‘noConflict’ method to avoid collision with other libraries that exposes the same variable name in globals.

Sophie: Sure. But how do you manage this problem in your source code?

Rita: Well, what I normally do is to expose an object variable in globals then I categorize my api depending the functionality that they are related to. For example:

File 1:

window.app = window.app || {};
window.app.url = window.app.url || {};
window.app.url.getParamByName = function (name){
  // Code.
};

 

File 2:

window.app = window.app || {};
window.app.url = window.app.url || {};
window.app.url.getHost = function () {
  // Code.
};

 

After loading this two files I have these two methods available:

  • window.app.url.getParamByName
  • window.app.url.getHost

Sophie: Nice! You already are using Design Patterns in your code, you see! This Design Pattern is a very basic way to lead with Namespaces. The Namespace pattern is a Structural Design pattern because you get the benefit to structure your code as you want without colliding between your code and third party libraries. jQuery namespace is $ but some other libraries were using $ before the first version of jQuery was released. Your code does the job but there are other ways to do the same that will give you more benefits.  For instance the benefit of having private properties or functions without exposing them.

Let me show you how is it possible:

File 1:

(function (ns){
  var _parseParams = function (){
    // Code
  };
  ns.url = ns.url || {};
  ns.url.getParamByName = function (name){
    var params = _parseParams();
    // Code.
  };
}(window.app || (window.app = {})));

 

File 2:

(function (ns) {
  ns.url = ns.url || {};
  ns.url.getHost = function () {
    // Code.
  };
}(window.app || (window.app = {})));

 

In these two files I am using one of the most used approach named IIFE (Immediately Invoked Function Expression) and it uses the function scope to hide the private,_parseParams without polluting your globals. That is a how to clean implementation of Namespaces.  With Javascript there are other ways, but you have to remember that IIFE is used extensively in Javascript to get other Design patterns working as the Module pattern.

Rita: Awesome, so I have been using Design Patterns without noticing them. I’m sorry Sophie but I have a meeting now, could we schedule another informal meeting to know more about Design Patterns?

Sophie: Of course!  I am quite sure you will have a lot of fun discovering how to improve your coding skills and most importantly how to reduce your lines of code and the complexity as well.  See you next time!

Tomás Corral
SENIOR FRONT-END CONSULTANT at BACKBASE
Tireless learner and tech teacher. Open source passionate, organiser of different frontend events and good friend.
Learning to program has been one of the most important things in my whole life because it really helped me to improve my way of thinking and acting everyday. Due to this fact and the lack of resources and people to help me in those old days, I decided to mentor other people to make their journey easier. (Colleagues, children and unemployed people)
I understand teaching as a way to deliver a part of myself to each of the people I teach to make them to be better people and developers.

Leave a Reply

Your email address will not be published. Required fields are marked *