• Post Reply Bookmark Topic Watch Topic
  • New Topic

Instance of an Interface  RSS feed

 
Jaime Caetano
Ranch Hand
Posts: 32
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey i'm getting into the interfaces and i'm back with another question dear folks.

I'm analysing the next code:



public class Image(){ }

public interface DisplayCriteria{
public void display( Image c);
}

public class Display{
public static void display(Image [] image, DisplayCriteria criteria){ }

}




--------------------------------------------------------------------------------------------------------------
Can I pass an instance of an interface like DisplayCriteria criteria on the paramater of a method?
this is confusing me cause you cant create an instance of an interface right?!

what could be an advantage of using this technic.

Jaime, Thanks

 
J. Kevin Robbins
Bartender
Posts: 1801
28
Chrome Eclipse IDE Firefox Browser jQuery Linux MySQL Database Netbeans IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct in that you can't create an instance of an interface. What that method signature does is allow you to pass any object that implements that interface.

You'll often see something like this:

That means the method will accept as a parameter any object that implements the Map interface such as a HashMap, TreeMap, etc. One reason this is done is because sometimes (often) requirements change and you realize that you need to implement things with a different type of collection than you had previously planned and this keeps code changes to a minimum. It gives you more flexibility. Think Abstraction, as in you are abstracting away the details. One of the basic principles of OOP.
 
fred rosenberger
lowercase baba
Bartender
Posts: 12563
49
Chrome Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know this helps, but it's an analogy I've written about before.

One thing you have to remember is that you won't always be writing all the code yourself. There could be multiple departments, or third party vendors you buy code from. Maybe that third-party code generates an object you want to use - perhaps for a database connection, perhaps to draw something on the screen...whatever.

all you know is you call a method they provide, and you get an object that does what you need. you have two options:

1) write your code to expect a concrete class.
2) write your code to expect an object that implements an interface.

Both really look more or less the same on your end:

ThirdPartyClass myNeatObject = callToSomeMethod(params);

or

ThirdPartyInterface myNeatInterfaceObjcet = callToSomeMethod(params);

both look and work about the same...until...

a year goes by. The vendor says "we have a new library. It now runs faster, has a smaller memory footprint, and does more cool stuff. you should start using it. It implements the same interface as the old version."

If you used the concrete class, you are screwed. Your code is expecting a ThirdPartyClass, but now the callToSomeMethod() returns a BetterThirdPartyClass object.

However, if you used an interface reference, the callToSomeMethod() returns an object that implements the same interface, so it just works.
 
Rico Felix
Ranch Hand
Posts: 411
5
IntelliJ IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Loose coupling is the advantage of using interfaces in your designs...
 
Jaime Caetano
Ranch Hand
Posts: 32
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you a lot for helping, I really appreciate it.

Jaime
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!