• 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
  • Liutauras Vilda
  • Paul Clapham
Sheriffs:
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
Bartenders:
  • Mike London

Interfaces, why do we have them?

 
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the advantage of using Interfaces in Java?

I know people will say it adds a layer to the system that hiues the functionality
of Class1 from Class2, but I mean pratically, from a developers point of view what's the advantage?
Because looking at the sample below, you have to call the class (CLass1) to create a new instance via
the Interface anyway.

What advantage does using the Interface give you?

Also when is/isn't a good time to use interfaces? Is there a sort of rule to it? I mean is it worth using an interface
for a Bean that just has a number of get/set methods (user details say) in it?



[EJFH: Fixed thread title]

[ November 28, 2007: Message edited by: Ernest Friedman-Hill ]
[ November 28, 2007: Message edited by: Keith Seller ]
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First, I think the title of your post should be "Interfaces, why do we need them?"

Second, you should declare that Class1 implements MyInt, otherwise you will not be able to assign an instance of it to a the "abc" reference, which is of type MyInt.

I think interfaces are mainly intended to allow the programmer to limit dependencies between different parts of his code. For instance if I write a sort method I can write it to take an instance of my special list class as an argument:



But I could also declare an interface List which exposes all the methods that I need to carry out the sorting and write a method that takes an object of that type:



Now my sort method is not dependent on MySpecialListClass. I only need to make sure that MySpecialListClass implements List.

I have changed the dependencies from



to



This means, for instance that I can change and recompile MySpecialListClass without recompiling the module that contains sort.
 
Kevin P Smith
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But are you (we) not just adding a layer of 'in-directness' (if that's a word) rather than direct calls between Class1 and CLass2?

Seems an Interface i there just to be there.

Don't get me wrong, I suse the because obviusly they'#re meat to be used, just don't fully understand a genuine advantage to them.

Is it OK to have an Interface which calls methods from multiple CLasses?

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Read Jan van Mansum 's reply one more time. Slowly.

Yes, you want to introduce the 'in-directness' (as you call it) into the code to de-couple the classes. So, in the future you can update/change the implementation of the method with [almost] no effect to the rest of the code.

This has more advantages in distributed applications. You will find out if you don't already know.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic