• 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

How Do I Implement a Java Interface?

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know what interfaces do. However, I have questions concerning how to implement one and need an example illustrating a simple implementation.
Q1) Is an interface definition required to be in a separate .java file?
Q2) Can an interface be in the same .java file as the method calling the interface's method(s)?
Q3) Are interface methods used only as temporary stub name references since they are not implemented with any code in the interface?
Q4) What happens if you call an interface method at run-time,
since the interface contains no code for the interface
method?
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) Generally, yes. Interfaces normally have public visibility and would therefore have to be declared in a .java file with the same name.
2) You may declare an interface in the same .java file as an implementing class (or any other class for that matter) as long as there is only one top-level public class or interface. Normally though, you would put your public interface declaration in a .java file by itself.
3) Interfaces are used to provide a layer of abstraction. They are useful when you know what services you want to be provided but do not know the exact nature of the classes that will provide the services. In general, programming to interfaces makes for greater flexibility. The drawback is that interfaces need to be designed more carefully because once they are published and used it is difficult to make changes to the interface.
4) Think of interfaces as "service contracts" that client classes can use to ensure that they will get whatever services they need. By declaring that it implements an interface, a class confirms that it does indeed provide all the services defined by the interface.
It's like buying a TV from a big appliance store chain and getting a service contract along with it. You can go to any store in that chain and be assured that you can get your TV serviced because you have the service contract.
But just as you wouldn't ask your service contract (the piece of paper that states that the store will service your TV) to fix your TV (you would go to store to get it fixed), you also wouldn't ask the interface to provide the services promised: you would ask the implementing object that promises to provide the services.
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

This was a very meaningful explanation of a rather conceptual topic.

"You can go to any store in that chain and be assured that you can get your TV serviced because you have the service contract. "
Can you elaborate on this please?

Thanks in advance
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To resurrect an old example - let's try Cars.
Say that I happen to work for the automotive industry and we are just getting into the Java coding business. However I want to leverage my code across lots of applications in the Division.
I know that we are eventually going to do LOTS of stuff with Car objects, and I want to make sure that we all work in unison.
So I make an interface called Car and in that interface I define all of the things that I want to make SURE that every thing that implements Car takes care of. So I put empty methods for Steering(), Break(), StartEngine(), Slowing(), WipeWindsheilds() and OpenDoor() etc. Every one in the department knows the methods that Car must do. It's all defined in the Interface. And, yes, we DO insist that all cars can Steer etc.
Now I make
abstract class Sedan implements Car{ }
abstract class Coupe implements Car{ }
abstract class Convertible implements Car{ } etc.
We all know that these classes have identical methods from Car and we know how to use them. Plus they may have their own methods - like Convertible may have a method OpenRoof() that Sedan does not have.
They must have the methods of the interface but maybe not ALL those methods are implemented (yet). Even if they were, you can not really build a Sedan, you have to build a specific model of a Sedan (like a Buick or a Cadillac). So I made the class abstract to prevent someone trying to make an instance of it. Eventually when the Buick class is created it will inherit all of the implemented methods that Car insisted on and all of the implemented methods that Sedan added, and Buick may have to add it's own implementation for any abstract methods that I may have left in Sedan. So extending the abstract class is a bit easier in that I don't HAVE to implement every one of those pesky methods, however it adds the danger of "typoing". With an interface you have to implement each and every method (and SPELL it correctly or the compiler complains). When sub-classing if you try to override a method and mis-spell it, it just becomes an additional method and the original method is still there and active - no compiler to give you a clue.
Anyway - back to interfaces:
I can now make "generic variables".
Cadillac c = new Cadillac();
Buick b = new Buick();
Car someCar = b;
someCar = c;
The someCar variable can hold any class that implements Car and we KNOW that it will be able to DO any of the methods defined in the Car interface. So now I can call someCar.StartEngine() even though I do NOT know what exact TYPE of car is being held in the someCar variable. I know because of that "service contract" that Junilu was talking about, the agreement that all cars would have this set of methods.

 
zaeem masood ashar
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow
What elaboration Cindy!! (By no means a Scream {Motion Picture} dialog)
Thanks


[This message has been edited by zaeem masood ashar (edited July 24, 2001).]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic