Loosely coupled JavaScript logic by observer & facade patterns in agile development
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.
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 :)
