This week's book giveaway is in the Java in General forum.
We're giving away four copies of Think Java: How to Think Like a Computer Scientist and have Allen B. Downey & Chris Mayfield on-line!
See this thread for details.
Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

disadvantages of interfaces

 
pravanya Gullapudi
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what are the disadvantages of interfaces?
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't see any. If you're lazy, it can be annoying to write "implements MyInterface" for each class implementing it
 
pravanya Gullapudi
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have been asked in interview.
 
Bupjae Lee
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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
Posts: 62
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Bloch came out against the idea in Effective Java

Thanks Jim. That reminded me to read this book !
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic