Power of Interface in Java
May 9th, 2008
I was working on compiling & refining Java/J2EE interview questions for the consulting company I'm with. One of the question really bothered me. It states, "What is the conceptual difference between "Abstract Class" and "Interface" ?". If you google for that question, I bet, you will come across tons of answers & explanations. To me, it's a cliche question you can almost expect that in any Java interview. I think it needs to be rephrased or asked in a different way. Here it goes...
What is the power of "Interface" in Java and support your answer with a practical example which could be understood by most Java programmers?
Answer: Interface helps in designing systems or software with high-level of abstraction. It helps design API and establish protocols between various systems being iteracted or interfaced. Let's take an example of java.sql.Connection. It totally depend on the implemented JDBC driver to define what the connection is doing. It could be a Oracle, MySQL database connection or it could be just a flat file based database connection. Same is the case with javax.servlet.Servlet interface. I can throw more & more examples. Anyway, the bottom line is... JDBC, Servlets, JMS, EJB etc. are all possible because of Interface.
I am not saying that is the best answer anyone can give or that is the only usage of Interface. Honestly, I should admit, I didn't know the real usage/power of Interface for a long time working in Java, until I reached a point where I felt... Yep... This is it. This is why interface was invented for...:)
I am not denying or underestimating the usage of abstract classes. And, I do think you can design APIs with just abstract classes. But, you almost had to fake some implementation to get high-level of abstraction. Abstraction is one of the biggest blessing in Software Programming. Think about OS level system calls, its all abstracted to the application level programs. We don't care how the file is being read or written at the byte level. As an application level programmer we do our job (of reading & writing file right by the application program we are working with) & expect the OS to do its job. I dont want to go off topic with all these metaphors. I think, I made my point clear.
Comments, thoughts ?
May 10th, 2008 at 08:54 PM I'm not sure I agree with your rephrasing of the question. I understand the point you are driving towards, and I would love to hear a candidate give such a thoughtful answer when I ask about abstract classes vs. interfaces. However, I would argue that you are leading too much with the question. In the last year, I have done over 100 interviews, mostly first or second phone screens. Asking the same question to three different levels of candidate (college grad, ~5 years of experience and 15+ years of experience) should yield three different types answers. The college candidate should give me extremely rehearsed textbook answers. In addition, they should be able to exercise these concepts in the design question I ask later. The candidate with about 5 years of experience should be able to talk about practical benefits and have a good understanding of how these things are used. A lot of understanding of this concept shows up in the design question. Finally, the seasoned veteran should provide deep insight similar to what you have shown here. Asking the question as you have phrased it will alienate the college student because they won't know where to start. The 5-year candidate will find the question a bit tacky and double-guess what the point of the question really is. The seasoned vet will probably find the whole thing strange. To answer the other part of your post, you are missing a vital point. When you talk about the "power of interfaces" you refer to standards for all of your examples. Interfaces are great at specifying standards. Abstract classes help define frameworks. You cannot build an SDK out of interfaces. It doesn't give you anything but structure. In order to actually implement and distribute an implementation of one of these standards, you have to use abstract classes. You have to write functionality that can be seamlessly integrated with your client's derived classes.
May 11th, 2008 at 07:14 AM Brian, I totally agree with your points. One thing I forgot to mention was, I was grouping questions based on experience levels. And, the question I brought here is definitely not for entry level candidates. It's for intermediate or expert -level. Again, I am not putting down abstract classes in any way. Abstract classes are definitely needed in the places you mentioned. Just wanted to stress the usage & power of Intrefaces little bit :)
May 11th, 2008 at 10:12 AM I would say the main difference is, the interface is a contract, the abstractclass is already a stub for the implementation. By giving abstract classes you already decide on what class the further implementation is based on (yours). So you take more control over the exact implementation. This can be useful, but if you just want to have a contract how to communicate with your software, this would give an additional burden to other developers. A RandomAccessFile would be impossible, if DataInput and DataOutput were implementes as AbstractClasses. After all interfaces are java's way to model multiple inheritance
May 12th, 2008 at 01:48 AM The major difference as I see it is that an abstract class is tied to a specific hierarcy of classes. An interface is less coupled than that.