Clean Code — Day 1
As developers, writing code is what we do during most of our time. But writing good code is another story. I always find the impact of a well organized and architected code quite intriguing. But its not just about splitting code into different files. As your application becomes monstrous, managing code quality becomes a nightmare. I have been haunted by such nightmares every now and then. What rescued me every time was a design pattern from The Gang of Four. Over a period of time, I have developed an inclination towards some. And last night, I decided to cover them one by one in my upcoming posts. I hope, you find these useful.
The Mediator Pattern
This pattern solves a very common problem very elegantly and with simplicity. Let look at it.
Suppose you have an application which jumps back and forth between various views or pages. It can be a web application with multiple web pages or a Java Swing application with different JFrames and panels. Different events can cause your application to go to different views. For example, if a user clicks on a button, go to Sign in Page. Or if a user enters his username/password on a stand alone application, open the Terminal. Basically if ChangeX happens -> go to ViewY with DataZ. Here DataZ is some data required by the destination view Y.
This might not seem a problem at all at first, but for a fairly large application, this quickly becomes painful (may be a little exaggerated). Lets say you start on a page 1. From this page, the user can go to Page 2 and 3. So you add your logic to take the user to any of these pages in your Page 1.
Now a week later the you added some more pages and the navigation looks like this:
The interaction is now bit more complicated as you added more pages and therefore more navigation. And lastly, if you look at Page 1 and Page 4, they both respond to the same set of changes which takes the user to the same corresponding page. For example on multiple pages, you can have links to Sign up and Sign in pages.
The Naive Mess
If you didn’t think it through, you might duplicate code in your page 1 and 4 because they have the same Change -> View call flow. You can clearly see how this can result in lots of redundant and duplicate code. The mediator patterns solves this problem elegantly.
The Mighty Mediator Pattern
Create a mediator layer which manages all your navigation code like this:
Here we introduced a new module called the “Mediator” which deals with all the logic of navigating through the pages. For each page, the Mediator now takes care of the following:
- When to navigate to a different page (what changed in the source)
- How to navigate to a destination page from source page(lets say managing the URLs)
- How to pass the data required by the destination page (session token, for example)
Each source page reports the changes back to the mediator so that the mediator can figure out how to go to the destination page. For example, the page 1 might tell the mediator that the user has entered the username/password and tapped on sign in and the mediator will take the correct action accordingly.
I just scraped the surface of this pattern here. If you find it interesting, look at this great post about the Mediator Pattern and its implementation in Java.
Stay Tuned for the next pattern…
