In Parts One and Two we discussed interfaces, created one and implemented it against a scenario. In Part Three I’ll demonstrate how having the interface from the start could make life easier in the long run. To do this, I will take you through 2 different scenarios. The first demonstrates future developments using the interface. The second will demonstrate a common business problem and how an existing interface will help to overcome it.
Scenario One: Future developments with the interface
Lets pretend that we have our HR application, all finished and working. We have published it to the relevant users in the business and they are busy using it (lets also pretend that for once no one has any complaints about anything). Everything is working fine for a few months, but then the HR Director drops you an email one Monday morning.
Thanks for creating the application for us, but now we need to be able to use it in a web browser as well.
The console version is so 1990’s!!
Grumble grumble… ok, ok you think. Whats the first thing you do? You grab the fully documented source code to remind you how it all works. Of course, you don’t have that. You’ll have to open the source code up and have a look. Now, following the code through you can start to remember what the program does and flow of it. But what really helps here are the Interfaces! Why you ask? Well, you need to create a new front end for the application. What you don’t want to do is to have to recode the entire thing. Thanks to the interfaces, you can see what you have to implement, to couple the new user interface with the code core code that already exists! Brilliant, that makes life a lot easier! If you hadn’t of used interfaces, then you would be going through all of the existing user interface (console questions and answers in this case) and working out how things work. Nightmare!
Scenario Two: Integration – the common problem
Six months down the line, the HR Director drops you an email out of the blue. Apparently your company have signed a deal with another (AngryHR Limited). AngryHR have a system that does some complex calculations for an item that your company needs to work out. The calculation requires information from employee contracts. The HR Director wants you to help AngryHR plug their software in to your app!
From now on, the AngryHR app is going to drive your app, populating it with information!
So, you have to assist the AngryHR developer to interface with your application. Interface! Ah ha! Well this should be simple then. You can provide the details of the applications Interface to the AngryHR developer. He will see what he has to implement in his application to drive yours! Ok, there are other issues that will crop up as well, but the point here is that since you created and implemented an Interface in your application, another developer can easily work out what he/she needs to implement to make their application work with yours!
The Final Point
OK, so I provided two very simplified examples of why use interfaces. Personally, I have been working on an application now for nearly two years which contains multiple interfaces. Using them has made life a lot easier for myself and the other developer I work with. We can see what needs to be implemented when we expand on parts of the application. It has allowed us to create and use hundreds of unit and integration tests to make sure that we don’t break any of the thousands of lines of code as we continue development.
There is a lot of information on Interfaces if you search Google, some of the best point I have linked below.
I hope that this 3 part article has been of some use to someone!