JavaScript is a powerful but simple language and it’s simplicity sometimes can miss-guide our project to a mess. An agile development always begins with the foundation of the logic and by time new features and functionalities are being added, therefore a solid structure is a must in order to meet the future demands and extensions.

This article will try to demonstrate the power of design patterns in JavaScript by illustrating a scenario of a voice over IP client application. The reason of selecting this specific scenario is its increase in complicity over the time, in another word the application will begin with a set of simple specifications but as the project will progress tones of necessary features begin to show up and without having a correct structure in place it will become very hard to continue its development.

Scenario

The objective is to develop a client for voice over IP service which is able to handle calling and receiving calls. In order to reduce the complexity of the example this article will not go in depth about the peer to peer connection of the application.

As it can be seen above, the functionality is pretty straight forward but there are a lot of possibilities which will be requested in the future like handling the “No Answer”, “Busy”, “Call Waiting” and so on, therefore the logic should be designed the way that any kind of new feature can be added smoothly and with lowest impact on the main logic.

Loose coupling - Wikipedia

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

Open-closed principle - Wikipedia

In object-oriented programming, the open/closed principle states " software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its source code.

Observer pattern - Wikipedia

The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

Facade pattern - Wikipedia

Developers often use the facade design pattern when a system is very complex or difficult to understand because the system has a large number of interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client.

Class Diagram

As it can be seen in the diagram above by the use of facade pattern we have accomplished a simple gateway(Manager class) to our logic and the observer pattern(Event Handler) will take care of the loosely coupled relationship between CallHandler and DeviceHandler classes.

The EventHandler class is just a blue print which will be implemented in the Manager class and will be passed to the DeviceHandler and CallHandler so any changes which will be applied to either DeviceHander or CallHandler classes will not effect each other directly, instead both CallHandler and DeviceHandler classes have the choice to consume the events which have been fired in any of them without being dependent on each other directly therefore the developer can change then individually .

This combination of the design patterns has been extremely helpful in my projects and I hope you can benefit form it as well :)