• 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

Reference variable

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Frnds,

What is the use of storing child class object in to base class reference variable?

That is, I've seen many statements like the following,

List myList = new ArrayList();

instead of , we can declare more specific like this,

ArrayList myList = new ArrayList();

Why we are using the first statement for instantiation. Could anybody clarify my doubt?


Thanks,
Senthilrajan.
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This typically indicates that the rest of your code only depends on myList being of type List, rather that specifically being an instance of class ArrayList. (I write "typically", because once I saw code like this where later the coder wrote something like ((ArrayList)myList).ensureCapacity(value) ) Why is this useful? Sometimes it can simplify your view of the object (if the variables type has far fewer methods than the class -- but that's not particularily the case with List/ArrayList -- or if the variable's type's specification is looser than the class, for example if you had made your variable's type Collection), and it can make it easier to change the implementation: if you want to use LinkedList instead, you only have to change one line of code. Choosing a more general type, often an interface type is even more relevant in method parameter types and return types:
 
Ranch Hand
Posts: 1026
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Code to interface

Burn this in your brian.

This is one of the design principles which means always take the reference to super type. The super type doesn't have to be an interface. It can also be an abstract class.

Note:
If you quite comfortable with java programming buy a copy of "Head First Design Patterns". The book concentrates on non-J2EE patterns (Core patterns).
[ February 02, 2006: Message edited by: Vishnu Prakash ]
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vishnu Prakash:
Code to interface



Why?
 
Vishnu Prakash
Ranch Hand
Posts: 1026
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Design Principle:
Program to an interface and NOT to an implementation.



Here interface means super type. It can be an interface as well as abstract class. The point is take advantage of polymorphism and make sure that runtime object isn't hard-coded into your code.



First I will give a little description about the above classes.

We have two classes(Dog and Cat) which implements Animal interface. These are called "Behavioral classes" because their sole purpose of living is to produce sound. CallAnimal class helps us to invoke the makeSound() method of the "Behavioral classes" at run time.

Note:
It will be nice if you package the implementation classes and CallAnimal and jar it. Now the animal package can be shipped anywhere.


Runtime object isn't hard-coded into your code.



What do I mean by this. Image if you hard-coded CallAnimal class's getAnimal like
public void getAnimal(Dog animal) { }
This will NOT allow you to call the Cat class which also implements Animal interface.

So only I said program to an interface(super type)(Animal) and NOT to an implementation(Dog).

Instead of having a class like CallAnimal we could have hard-coded the instantiation of the sub-types like

Dog dog = new Dog();
dog.makeSound();

But hard-coding the instantiation of the sub-type Object doesn't help you to take advantage of polymorphism.

Always assign the implementation object at runtime.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is that discussion relevant to the original poster and his question? He was only wondering why the following line of code was written with "List" instead of "ArrayList":

The enclosing class isn't a polymorphic container like CallAnimal. Your final comment to "Always assign the implementation object at runtime" would almost certainly be overkill is his case: death by lethal dependency injection.

Everything you wrote is true, but irrelevant to the original poster. I think that while using sound object-oriented design sounds like it is a good thing, so is simplicitly. Over-engineering can be a bad thing.
reply
    Bookmark Topic Watch Topic
  • New Topic