Welcome!

This weblog was the original abode of Abhijit Nadgouda, now it is moved to iface thoughts. He will appreciate it if you can carry discussions, if you want to, over there. He uses this blog to write specifically about Wordpress or Wordpress.com.

If you are reading any specific post dated on or before 17th August 2006, just replace the domain name with the new one, i.e., replace https://iface.wordpress.com with http://ifacethoughts.net and you will arrive on the same post in the new blog.

Flickr Photos

Affiliations

Traffic

64,886 hits

What Is Interface?

February 6, 2006 — Abhijit Nadgouda

I started by 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 infactuation 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 inheritance 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 Java World about interfaces and how they helped OOP 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 passenter if he was travelling by the bus and not driving it. I realised that, however impersonal it my sound, I did identify certain people just by what they did and not by their name. Lots of real-life example 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 the “functionality” from an “entity” (living or non-living thing), leading the following possibilities:

Because the functionality was explicity 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 did not need to 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 dirvers 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, wihtout 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.

Like this:

Related

5 Responses to “What Is Interface?”

[…] We have seen in the What Is Interface? post that an interface isolates the role (functionality) from the entity (who performs the functionality). This helps the servers (providers of the service) and its clients (users of the service) to communicate with each other. For the interface to be effective, the server should make sure that its language is understood by its clients. […]

[…] Some of these terms do overlap. API is the interface provided by the library, toolkit or the framework. This interface, usually, works like a contract between the creator and the user. Library is a generic term for a group of functionality provided. These libraries together can form a toolkit or a framework. Gang of Four (GoF) explain the difference between toolkits and frameworks in Design Patterns – Elements of Reusable Object-Oriented Software: A toolkit is a set of related and reusable classes design to provide useful, general purpose functionality. Toolkits don’t impose a particular design on your application; they just provide the functionality that can help your application do its job. They let you as an implementer avoid recoding common functionality. Toolkits emphasize code reuse. They are the object-oriented equivalent of subroutine libraries. […]

[…] Titled as The C++ Style Sweet Spot and Modern C++ Style, the discussion answers some principle questions about moving from C to C++, using inhertiance the right way, using abstract classes for interface and considering the invariant for designing simple classes. If you haven’t read them yet, jump right ahead and consume them, the provide lot of food for thought and can act as design guidelines. […]

Thanks for your kind words. The purpose of this article was not to define the keywords we use in programming languages, but that the fundamentals of interface are completely derived from the real world.

By this paradigm, even an abstract class exposes an interface.

However, I will definitely elaborate on this and include discussions and usage of the programming keywords.

I have moved this post to my new blog. I will appreciate if we continue this discussion there.