aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes using Interface reference for objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "using Interface reference for objects" Watch "using Interface reference for objects" New topic
Author

using Interface reference for objects

ronnir paterl
Greenhorn

Joined: Oct 18, 2007
Posts: 11
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
Nabila Mohammad
Ranch Hand

Joined: Nov 05, 2007
Posts: 661
I was wondering the same thing...


The future belongs to those who believe in the beauty of their dreams.Dream BIG!
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

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 ]

There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. --Bill James
Ivan Ivanic
Ranch Hand

Joined: Oct 31, 2007
Posts: 100
i would add:
if you program to interfaces you are achieving loose coupling. In example:
if you have:

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.


<a href="http://faq.javaranch.com/java/UseRealWords" target="_blank" rel="nofollow">Use Real Words</a> <a href="http://faq.javaranch.com/java/UseCodeTags" target="_blank" rel="nofollow">!!!Use Code Tags!!!</a> <a href="http://faq.javaranch.com/java/SayThanks" target="_blank" rel="nofollow">Say Thanks</a><br />scjp6
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

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.
Ivan Ivanic
Ranch Hand

Joined: Oct 31, 2007
Posts: 100
thanks Stevi, I will remember this. Still learning
Dinesh Tahiliani
Ranch Hand

Joined: Aug 06, 2007
Posts: 486
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


Thanks<br />Dinesh
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

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 ]
Dinesh Tahiliani
Ranch Hand

Joined: Aug 06, 2007
Posts: 486
What about memeber variables.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42285
    
  64
Originally posted by Dinesh Tahiliani:
What about memeber variables.

Interfaces don't contain fields, only methods.


Ping & DNS - my free Android networking tools app
Stevi Deter
Ranch Hand

Joined: Mar 22, 2008
Posts: 265

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

Joined: Oct 31, 2007
Posts: 100
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
Ivan Ivanic
Ranch Hand

Joined: Oct 31, 2007
Posts: 100
interfaces can declare constants...
[ April 28, 2008: Message edited by: Ivan Ivanic ]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: using Interface reference for objects