wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes disadvantages of interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "disadvantages of interfaces" Watch "disadvantages of interfaces" New topic
Author

disadvantages of interfaces

pravanya Gullapudi
Greenhorn

Joined: May 07, 2007
Posts: 16
what are the disadvantages of interfaces?
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

I can't see any. If you're lazy, it can be annoying to write "implements MyInterface" for each class implementing it


[My Blog]
All roads lead to JavaRanch
pravanya Gullapudi
Greenhorn

Joined: May 07, 2007
Posts: 16
i have been asked in interview.
Bupjae Lee
Ranch Hand

Joined: May 14, 2007
Posts: 107
Interface has much less restriction than class in the view of inheritance, so someone may abuse interface (i.e. making too much interface and implementing them).

One example is "Constant Interface" antipattern; you can refer this site
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

From that site :
"Sometimes, people place static members into an interface and inherit from it looking for avoiding prefixing static members with class names."
Wow, who the hell does that ?
Bupjae Lee
Ranch Hand

Joined: May 14, 2007
Posts: 107
"Sometimes, people place static members into an interface and inherit from it looking for avoiding prefixing static members with class names."
Wow, who the hell does that ?


Unfortunely, javax.swing.WindowConstants does that; JDialog, JFrame, and JInternalFrame implement this interface.
Marcos R Oliveira
Ranch Hand

Joined: Apr 20, 2002
Posts: 51
Hi,


Unfortunely, javax.swing.WindowConstants does that; JDialog, JFrame, and JInternalFrame implement this interface.


But not because is avoiding prefixing static members with class names. Or is it?


SCJP 1.4 - SCJP 1.6 - SCWCD in progress
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Satou]: Wow, who the hell does that ?

It was advocated by various people for awhile. For example Craig Larman recommended it in Java 2 Performance and Idiom Guide, 2000. Josh Bloch came out against the idea in Effective Java, 2001, and I don't think anyone's really been endorsing the idea since then.

[Bupjae Lee]: Unfortunely, javax.swing.WindowConstants does that; JDialog, JFrame, and JInternalFrame implement this interface.

[Marcos]: But not because is avoiding prefixing static members with class names. Or is it?


I agree. WindowConstants is actually a relatively sensible use of this idiom, because the point it is to publish constant values that users of the Swing classes need, in order to use the classes. Those constants are supposed to be part of the public API. If the same classes were designed today, WindowConstants would probably be replaced with a public enum instead.

A better example of a poor use of a constant interface would be ObjectStreamConstants, used by ObjectInputStream, ObjectOutputStream, and others. These constants are really used only internally by the classes that implement the interface; they are of no interest to programmers who are simply using the classes. They just clutter up the API and make it harder to understand.


"I'm not back." - Bill Harding, Twister
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
One disadvantage of interfaces is that one you publish them to other coders outside your own control, they represent a public commitment which can be difficult to change later. You don't know who else is using the interface and you don't know how, so you can't just add a new method to the interface without risking breaking the code of existing clients (if/when they upgrade). In comparison, if you'd used an abstract or concrete class, you could just add a new concrete method with no problems (usually).

It's possible to work around this by creating a new interface with extends or supplements the original one, and changing your concrete implementations to implement the new interface, instead of or in addition to the old one. That way you don't break existing client code. It's generally more work than adding a method to a class would be, but it's possible.

This disadvantage isn't a reason to abandon interfaces, but it is a reason to design your interfaces carefully, and think carefully before you publish a new interface in a new release. Spending some extra time designing things well now can save you many headaches later.
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

Josh Bloch came out against the idea in Effective Java

Thanks Jim. That reminded me to read this book !
 
jQuery in Action, 2nd edition
 
subject: disadvantages of interfaces