What is Interface?

by Abhijit Nadgouda

Length: 837 words

I started my software programming adventure when I was in the college. The earliest phase was when the focus was on programming skills more than the purpose of programming. The next phase was infatuation with C++ as an object oriented programming language - its possibilities, its standards, its flexibility and hence the complexity. I came across Java as another object oriented language and discovered "interface". I found it interesting in the beginning, then intriguing and finally irritating. I could not understand the advantages of using an interface. I gathered from books that interfaces were useful in Java because it did not support multiple inheritances with classes. But this was not enough to convince me, and so I decided to indulge a bit to find out whether interfaces were indeed useful, or were just a syntactical binding on a programmer.

As I explored deeper, I read an article on http://www.javaworld.com about interfaces and how they helped OOPS in designing real-life scenarios. This made me wonder if we used interfaces in the real life. I started considering examples. Did I identify the driver of my bus as he drove the bus and not by his name, the conductor because he checked the tickets or the passengers because they travelled by bus? The same driver would become a passenger if he was travelling by the bus and not driving it. I realised that, however impersonal it may sound, I did identify certain people just by what they did and not by their name. Lots of real-life examples started flashing before my eyes - the postman, the librarian, the doctor. I thought I had the answer to my question. This reached the next level when our usual postman was replaced by someone else, but he still did deliver the letter to me. This made me realise that "postman" was not the person, but the role. So, the function of "delivering letters" applied to the role of the postman. I concluded that functionality or a set of functions defined roles.

After this newfound realisation, I began identifying everyone with what they did, and this helped me a lot in my software designing and programming activity. I had to understand "interface in real-life" to understand the applications of "interface in Java" which evolved to "interface in designing" with time. Using this I could call the same person a driver or a passenger, or could address another person as a driver. This way the transport system or I had to rely only on the driving ability, and not on any person for the driver's role. What was required was to advertise for people who performed the function of driving. And I as a passenger did not need to know how driver drove the bus.

This is what interface does: It allows a system to isolate "functionality" from an "entity" (living or non-living thing), leading the following possibilities:

• Because the functionality was explicitly identified, the transport system could use it to advertise its requirements.
• The transport system knew the requirements for hiring more drivers, and could reduce its dependency on a single person.
• The passengers did not need to know the technical details of driving the bus.
• Whenever the requirements would change - e.g. the driver should also follow the traffic rules in addition to driving the bus - the transport system could change its functionality for the "driver" and make sure that all the drivers complied with this functionality. It helped the passengers of the transport system, as they need not depend on one person. The interface (functionality) of a driver became one of the ways in which the passengers started using the transport system. The passengers did not care from where the transport system got the drivers or whether they were machines or humans as long as they "did their job" - "performed their functions" - "complied with the driver's interface".

I reached the conclusion that an interface is used by a server (transport system) to communicate with the clients (passengers).

The function pointers in the callback mechanisms or event handlers are interfaces of the functions. The function is invoked, without needing to know how it is implemented.

When a C utilities library is built, the programs that use it don't need to know the code inside the library, all they need to know is the signature of the functions to use. This set of functions is an interface.

Like in the case when the passengers did not need to know the technicalities of driving the bus, the interface allows to hide the implementation. It separates "what" from "how" of any system.

Related Posts

• Designing an Effective Interface

Article filed under:

TOPIC>Information Technology>
PUBLICATION>ManojKhatri.com>
EDITORIAL TYPE>Non-Fiction>Feature>

About the author/s

• A software engineer who has an understanding of business, ears for the customer, brain of a designer, hands of a developer and hope to become an author :-) Checkout <a title="Abhijit Nadgouda's blog" href="http://ifacethoughts.net">my blog</a>.