This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Coding to an interface

 
Gaurav Arora
Ranch Hand
Posts: 35
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read about coding to an interface time and again. I also understand that the practice builds flexibility in your code and flexibility is never a bad thing, well almost never. All in all, it's a good practice and I agree with it.

My question is, does it help (or hurt) performance of an application in any way?
 
Peter Chase
Ranch Hand
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gaurav Arora:
flexibility is never a bad thing


I'm not sure I agree with this.

Flexibility is good if it helps with current requirements, or genuinely likely future requirements. Flexibility is also good, if it can be achieved without additional complication.

Flexibility that is not needed now, and has only speculative use in the future, but which adds complication, is bad. It costs money to implement. It costs money to debug the extra complexity. It costs money to maintain the more-complex code.

An example of bad flexibility I've often encountered is over-generalisation. An interface that could have been simple has been made complex to understand and to implement, for the sake of generality for which there was no need at the time, and for which no need has arisen in the years afterwards.

Remember, YAGNI.
 
Rob Spoor
Sheriff
Pie
Posts: 20386
46
Chrome Eclipse IDE Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Normally it doesn't. You still have the same objects with the same methods and fields. The code doesn't change (much) if you declare something as List or as ArrayList.

Of course, when you want to perform specific code for certain implementations, then you will need to a) check if the object is an instance of the class, and b) cast. This will hurt performance - albeit only slightly. You won't even notice the difference.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Pie
Posts: 15150
31
Android IntelliJ IDE Java Scala Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rob Prime:
Normally it doesn't. You still have the same objects with the same methods and fields. The code doesn't change (much) if you declare something as List or as ArrayList.

Of course, when you want to perform specific code for certain implementations, then you will need to a) check if the object is an instance of the class, and b) cast. This will hurt performance - albeit only slightly. You won't even notice the difference.

Note that if you find that you need to use 'instanceof' or casts, it's a sign that the design of your software might have a flaw somewhere. In a well-designed piece of software, you shouldn't need to use 'instanceof' or casts.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic