• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Coding to an interface

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic