Program to an abstraction rather than a concrete type – Theory example

Another generalized ground rule always mentioned when Interfaces or Object oriented design is discussed is the following:

“Program to an abstraction rather than a concrete type”

But what does this really translate to? …

One can more easily put it as: “Program to an Interface rather than a concrete class”

As an Interface can be seen as a type of contract (as described earlier on), it thus can be distilled that we want to program to the contract rather than to an instance of a class.

This statement can be seen from two sides:

1. The class that is implementing the interface.
2. The class that will be using the interface.

So let’s look at the following example which touches on both points one and two.

We have an international company with its head office in London and branches in numerous places in the world: Sweden, America and Germany. Each country has its own IT department that does some development on the main system supplied by the head office in London. Until now the accounting system was software purchased and supported by an external company, however recently the decision was taken to develop our own in-house Accounting system.

The main part of the accounting system will be developed at the head office in London. Because of the fact that tax legislation differs so vastly from country to country, it was decided to let each country develop their own tax module. This will then be used by the developers of the main accounting system to complete the Tax functionality of the account system.

The problem presented here is that of parallel development. The writing of the main system is dependent on the content of the tax modules that will be written by each country. This could imply that the developers of the main system need to wait on the completion of the tax module being written by each country. Problems / unknowns that could arise could include the following:

• What are the module / class names that will be used by each country?
• What will the function names be that need to be called?
• What will the input and output parameters be? What will the data types be?
• Will there be any special way of calling the methods? Maybe one needs to set certain properties first or get the return value from a property.
• The list goes on …

Well one could argue that you could write detail specification etc. etc. to get around the above stated problems, but there is a far neater solution – Interfaces!

So as the topic states “program to an interface not an implementation” ­ let’s start by creating an interface ITax and assume for the moment that this interface contains only one function – CalculateTax()

And what would the purpose be of the CalculateTax() function? -> The purpose would be to perform the Tax calculation per country.

Each country’s developing team responsible for the Tax module; will receive this interface – which in essence is just a file. The point being that:

1. They must implement the interface on the Tax module they are developing.
2. The CalculateTax() function must be implemented in the module. This should be no problem as this will be enforced by the compiler.
3. When a component within the main accounting system requires a tax calculation from a specific country, the CalculateTax() function will be called via the interface that was implemented on their tax module / class.

How does this help us?

Well the problem was that the team working on the main system in London needed to wait on the tax modules / classes that will be written by the different countries’ teams in order to code against them. This has now been solved by letting the team developing the main system in London code against the interface and not the classes! They can now proceed with their work knowing that:

1. This interface will always be available for each country’s Tax module.
2. That CalculateTax() will be the function to call on the interface for tax calculations.
3. They will know to always pass it the amount as a double datatype.
4. They will know that the return datatype will always be a double.

Main system will thus make use of this interface to continue the development of their code by: “programing to an interface rather than a concrete type (class)”

By implementing the interface we have succeeded in creating a unified way of accessing functionality in all Tax classes. This means that the users of the interface are able to access different classes in exactly the same way. The tax calculation within CalculateTax(), differs drastically between countries. This is most notably seen when comparing the calculation of Sweden and that of America. For the user of the interface however the specifics of the calculation are irrelevant. It just knows that the CalculateTax() function on the ITax interface returns the correct value.

Of course this is just one of the many advantage that comes with the usage of interfaces. Building systems that are loosely coupled is also achieved by making use of interfaces. This will be looked at in the section: Interfaces the flexible ‘link’ between components – Demo