Declare an object as its parent class?

[Tookelso]

Is there any reason to declare an object as its Parent or Grandparent
class, then instantiate it as the intended class?

Example:

Class Oven { blah }
Class Microwave extends Oven { blah }

main function
// Note here we declare it as an Oven, but instantiate as a
Microwave
Oven myMicrowave = new Microwave

This seems to have no useful purpose. Why not just declare everything
as an Object, then instantiate as its own object. This seems to
propogate un-necessary casting.

Opinions? This code is all over the place at my workplace, and is
confusing and aggravating.

 

[Oscar kind]

Is there any reason to declare an object as its Parent or Grandparent
class, then instantiate it as the intended class? [...]
This seems to have no useful purpose. Why not just declare everything
as an Object, then instantiate as its own object. This seems to
propogate un-necessary casting.

Opinions? This code is all over the place at my workplace, and is
confusing and aggravating.

Because an Object does not have the methods you likely want to use.

You specify a superclass or an interface because it defines the
functionality you need (but no more). This allows you to switch
implementations when nescessary without changing all those references
to the subclasses.

You instantiate a subclass or an implementing class because it has
specific functionality that makes the object efficient in the specific
case (even though a superclass/interface is sufficient for the code).


Also note, that you don't need to know what specific (sub)class is
instantiated. In fact, you cannot always know, since the object you get
may actually be some anonymous class instance. All you need to know is
that it is (a subclass of) a specific class, or that it implements a
certain interface. That's enough to work with it.

 

[Chris Smith]

Is there any reason to declare an object as its Parent or Grandparent
class, then instantiate it as the intended class?

Yes. See below.

This seems to have no useful purpose. Why not just declare everything
as an Object, then instantiate as its own object. This seems to
propogate un-necessary casting.

Opinions? This code is all over the place at my workplace, and is
confusing and aggravating.

It appears that someone is doing things wrong at your workplace. The
reason you'd declare a variable with a less specific type that you
intend to localize the knowledge of the exact class of the object. If
it's being frequently cast back to the more specific type, then this
defeats the purpose and is indeed a very poor idea.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Steve Horsley]

Is there any reason to declare an object as its Parent or Grandparent
class, then instantiate it as the intended class?

Oh yes.

Example:

Class Oven { blah }
Class Microwave extends Oven { blah }

main function
// Note here we declare it as an Oven, but instantiate as a
Microwave
Oven myMicrowave = new Microwave

An example that I seem to use nearly every day:

import java.util.*;

List widgets = new ArrayList();
// start putting things in the List.

This seems to have no useful purpose. Why not just declare everything
as an Object, then instantiate as its own object. This seems to
propogate un-necessary casting.

Opinions? This code is all over the place at my workplace, and is
confusing and aggravating.

The idea here is that if you stick to using the least specific superclass
then you can slip in a different implementation with ease. In the example
I gave, if all my code simply declares List, I can change one line and
use an ArrayList, LinkedList, Vector or any other implementation of List
depending on the results of performance testing ot whatever.

This is especially important for writing methods that accept a range of
interface implementations or sub-types. Perfect example:
List widgets = getWidgetList(); // could be one of many List types
printer.printAll(widgets);
No need for overloading a new printAll() method for every possible list
type - just one method accepting a List.

Yes, I know that in this case I'm talking about an interface rather than a
superclass, but the same principle applies. For a superclass example, look
at javax.swing and Container.add(Component), where Component could be
a button, text-box, ScrollPanel, anything.

But as Chris says, if you keep having to cast it back to the more specific
type to get access to more specific methods, there is something wrong.

Steve.