using Interface reference for objects

Hi,

I am a bit confused about references of interfaces. As I understand there are two ways to instantiate an class object that implements an interface.

a. by using interface reference
b. by using class reference

for e.g

Set a = new HashSet
or
HashSet a = new HashSet

So, are there any advantages of using one format over the other or is it simply a matter of preference.

Any help would be appreciated.

Thanks

I was wondering the same thing...

As a general rule, use the most abstract reference object you can, especially in any externally facing element of your application (e.g., the public properties and methods, or API).

For example, it's better to use Set<T>:

Set<String> aSet = new HashSet<String>();

(It's even better to use Collection<T> if you can.)

This practices helps aid in encapsulation, by hiding implementation details.

For example, perhaps you initially think HashSet<T> is the right implemenation to use. You start your code, then realize what you really need is TreeSet<T>. Or even to write your own Set<T> implementation.

If all your external references are to HashSet<T>, you have to update larger parts of your program.

If your public accessors are all Set<T>, however, you only have to modify the affected class, thus minimizing the ripple effect of the change.

Which is a significant benefit of well-thought out Object Oriented Design.

If you find in your code that you feel forced to declare public methods or properties with specific classes instead of interfaces (when applicable), it's often a sign you need to reexamine the design.

[ April 25, 2008: Message edited by: Stevi Deter ]
[ April 25, 2008: Message edited by: Stevi Deter ]

i would add:
if you program to interfaces you are achieving loose coupling. In example:
if you have:

public class Eater{
  public eat(Eatable e){
    //eat Eatable object no matter what is objects type
    //this Eater only cares that it is Eatable and that it can call
    // it's eatMe() method...
    e.eatMe(); //here Eater don't need to know anything else about e
  }
}
 
public interface Eatable{
   public void eatMe();// all Eatable objects must have this behavior
}
 
public class Apple implements Eatable{
  public void eatMe() {
    System.out.print("Apple eated");
  }
  // a lot of other code
}
 
public class Paper implements Eatable{
  public void eatMe() {
    System.out.print("Paper eated");
  }
  // a lot of other code
}
 
public class TestEating {
  public static void main(String[]a) {
    Eater eater = new Eater();
    Apple apple = new Apple();
    Paper paper = new Paper();
 
    eater.eat(apple);// here eater doesn't know anything else
    eater.eat(paper);// about this two objects, except that they are
                     // eatable, thus you have a very loose coupling
  }
}

Hope this helps you understand that you can choose how you are gonna program - to interfaces of concrete implementations - but that you should always program to interfaces.

I would caution against the prescription to "always" program to interfaces.

Rather, use when it fits the need.

For example, on the large N-Tier projects I've worked on, it has always been of benefit to program the service layer and DAO to interfaces. This lets us use tools like Spring to isolate various elements, swap in and out implementations between JDBC and Hibernate, etc., with ease.

But I've never found it useful to program the actual model or the presentation layer to interfaces. Any attempt usually just results in the sort of difficult to maintain and understand code that makes some people criticize Java.

In Java, the "always" is always think about what patterns, methods, and approaches to object oriented design are going to help you write clean, readable, maintainable code.

thanks Stevi, I will remember this. Still learning

What i see in your code is public used many times. A source file can have only one public class.
Morever the interface can't be public I think it is defaultly public. Correct mei am wrong .

class Eater
{
public void eat(Eatable e)
{
//eat Eatable object no matter what is objects type
//this Eater only cares that it is Eatable and that it can call
// it's eatMe() method...
e.eatMe();
//here Eater don't need to know anything else about e
}
}
interface Eatable
{
public void eatMe();// all Eatable objects must have this behavior
}
class Apple implements Eatable
{
public void eatMe()
{
System.out.println("Apple eated");
}
// a lot of other code
}
class Paper implements Eatable
{
public void eatMe()
{
System.out.println("Paper eated");
}
// a lot of other code
}
public class TestEating
{
public static void main(String[]a)
{
Eater eater = new Eater();
Apple apple = new Apple();
Paper paper = new Paper();
eater.eat(apple);// here eater doesn't know anything else
eater.eat(paper);// about this two objects, except that they are // eatable, thus you have a very loose coupling }}
}
}

o/p - Apple eated
Paper eated

Originally posted by Dinesh Tahiliani:

Morever the interface can't be public I think it is defaultly public. Correct mei am wrong .

Actually, it's the methods of an interface that are implicitly declared public. For full details about what access modifiers are valid for interfaces and when, see the Java Language Specification.
[ April 28, 2008: Message edited by: Stevi Deter ]

What about memeber variables.

Originally posted by Dinesh Tahiliani:
What about memeber variables.

Interfaces don't contain fields, only methods.

Interfaces can declare fields, but they are implicitly public, static, and final.
[ April 28, 2008: Message edited by: Stevi Deter ]

Originally posted by Dinesh Tahiliani:
What i see in your code is public used many times. A source file can have only one public class.
Morever the interface can't be public I think it is defaultly public. Correct mei am wrong .

I never said it is one source file

public interface Cloneable

interfaces can declare constants...

[ April 28, 2008: Message edited by: Ivan Ivanic ]