OOP Object Construction

[B Sleek]

I would like to create a new object by converting an object of a base class to the type of a sub class.

For instance, if I have the below classes... If I want to create a Ball object before I know what type of ball it is. How would I create a football from the ball without having to explicitly set all my base class member data again.

Super() seems like no help because I still have to either provide an overloaded constructor, or explicity reset my instance data.

class Ball() {
 
   int size;
   String color;

   Ball(int inSize, String inColor){
      
       // set properties
 
   } 
 
} // end Class
 
 
class Football extends Ball() {
 
  String brandname;
 
  Football(){
  }
 
}
 
 
myBall b = new Ball(10, "red");
 
//create new Football based on current Ball?
 

[ December 13, 2004: Message edited by: B Sleek ]

[Stefan Krompass]

Hi,

why do you want to create an object of the superclass? I don't see why this is necessary...
If we knew more about what you want to achieve, we could try to find another solution.

Stefan

[William Brogden]

I would like to create a new object by converting an object of a base class to the type of a sub class

You can't convert an object to another type.
You could create a constructor that takes a reference to the original object but it would still have to explicitly initialize all the variables.
Bill

[B Sleek]

You could create a constructor that takes a reference to the original object but it would still have to explicitly initialize all the variables.

Isn't this redundant?

I mean if I my base class is clearly defined why must "promoting" my object be so round-a-bout?

[Joel McNary]

Why create a Ball in the first place? Promoting an object is round-a-bout because of all of the things that happen behind the scenes -- you would have to reallocate memory (the structure size of the sub-object is likely to be larger than the base object) and there are any number of little "gotchas" that are likely to make such an operation not overly happy.

Instead, what you could do is create a Factory class that churns out Balls of some type based on different conditions -- a .properties file, the current locale, etc. In this case, you probably want pass a parameter to the factory indicating what type of object to create.

public class BallFactory{
    BallFactory singleFactory = new BallFactory();
 
    private BallFactory(){
        ; //Make it private so that it cannot be instantiated
    }
 
    public static getInstance(){
        return singleFactory;
    }
 
    public Ball makeNewBall(String class, int size, String color){
         Class ballClass = Class.forName(class);
         java.lang.reflect.Constructor aConstructor = 
           ballClass.getConstructor(new Class[]{int.class, String.class});
         Ball aBall = (Ball)aConstructor.newInstance(new Integer(size), color);
         return aBall;
    }
}

And then you get your Football by calling:

//...
    Football b = (Football)BallFactory.getInstance("Football", 10, "red");
    b.brandname = "Spalding";
//...

Of course, you would discover that this wouldn't quite work, as Football doesn't define a Constructor that takes an int and a String. (Constructors are not inherited....)

So your choice would then either be to create the appropriate constructor for Football or to remove the parameterized constructor and use the no-argument constructor. (I personally favor the latter). Then your code would read:

//...
    Football b = (Football)BallFactory.getInstance("Football");
    b.size = 10;
    b.color = "red";
    b.brandname = "Spalding";
//...

Of course, you would have to make the appropriate changes in the BallFactory class:

//...
    public Ball makeNewBall(String class){
         Class ballClass = Class.forName(class);
         Ball aBall = (Ball)ballClass.newInstance();
         return aBall;
    }
//...

Add in the exception handling, and you're done!
[ December 13, 2004: Message edited by: Joel McNary ]

[B Sleek]

Stefan-

Suppose hypothetically ball's had their own behavior, and only certain types of balls would be eligible to become "specialized" balls. At that time they would still keep their characteristics as ball objects.

*Kicks himself for poor name choice of base class*

[B Sleek]

Joel-

My base objects have functionality over a certain lifetime some of them may never become objects belonging to the subclass. What I am trying to avoid is re-initializing the instance data of my base objects. The main reason is that subsequent changes to my base class will require ALL my object conversions to change.

[Paul Santa Maria]

B Sleek - I think Joel hit it on the head.

If I'm understanding you correctly, I think what you're looking for is the "Factory" pattern. Client(s) that want to use your class don't "new Ball()" (or any subclass of "Ball") directly. Instead, they call your class's static "getInstance()" method. GetInstance(), in turn, figures out the "right" kind of "Ball" object to create, and then passes that reference back to your client(s). To the client, it looks like a generic "Ball". Under the covers, it can be as specialized as you want.

'Hope that helps .. PSM
[ December 13, 2004: Message edited by: Paul Santa Maria ]

[William Brogden]

My base objects have functionality over a certain lifetime some of them may never become objects belonging to the subclass. What I am trying to avoid is re-initializing the instance data of my base objects. The main reason is that subsequent changes to my base class will require ALL my object conversions to change.

You still seem to be nourishing the delusion that you can change the type of an existing object. You will have to drop that and take a fresh look at your problem.
Perhaps you need to be able to add functionality to a "base" object by enclosing it in different "wrappers." This may be a case for the "Decorator Pattern" - as used to great effect in the java.io package where an InputStream can be used to construct (wrapped in) a variety of objects that add functionality - such as buffering.
Bill

[Stan James]

I'm with decorator. Instead of putting the different behavior in subclasses of Ball put them in subclasses of, um, Bounce. So Ball starts out with a DefaultBounce behavior. If you decide your ball is a football, replace DefaultBounce with FootballBounce and watch it bounce funny. So your Ball has something like this:

public void bounce()
{
   myCurrentBounceBehavior.bounce();
}
public void setBounceBehavior(BounceBehavior bb)
{
   myCurrentBounceBehavior = bb;
}

[B Sleek]

I understand that I could add behavior to my base class by wrapping the object but that does not help me add NEW data to the objects. A ball is not a Football. You can throw both the balls, true, but all balls won't have "seems" etc.

I'll accept the fact that this can't be done the way I want to do it, and is not a scenario that comes up everyday. However I am still struggling to see WHY the instance data belonging to my parent class can not be inherited to child objects. I'll be happy if I knew there is some low level language obstacle that prevents this, or there is an effective alternative method, or a good reason never to do this.

[Joel McNary]

This is the basic reason:

The structure size of the sub-object is likely to be larger than the base object

Thus, to "promote" an object, the underlying struct size would have to change. Java doesn't do this. Period. Could it? possibly. Is is necessarily a good idea? Maybe, but probably not.

That said, there are other ways to do what you want to do. Consider using the DecoratorPattern, mentioned above, with a Map to store attributes:

class Ball() {
    java.util.Map attributes = new java.util.HashMap();
 
    Ball(int inSize, String inColor){
        // set properties
        attributes.set("_TYPE", "Ball");
        attributes.set("Size", new Integer(inSize));
        attributes.set("Color", inColor);
    }
    
    public int getSize(){
       if(attributes.get("Size")==null){
           return 0;
       }
       else{
          return ((Integer)attributes.get("Size")).intValue();
       }
     }
 
     //Do somethign similar for Color...
 
     public Object getAttribute(String name){
          return attributes.get(name);
     }
 
     public Object setAttribute(String name, Object value){
          attributes.put(name, value);
     }
} // end Class 

Now you essentially have a dynamically-sized class, ready to hold whatever attributes you deem fit. Of course, this gets around most of the type-safety checking the compiler does (the compiler will be unable to tell a Ball from a Football), so prepare to handle a bit of run-time exceptions (and prepare to write them, too, like "UnsupportedOperationException" or "IllegalArgumentException" -- Those can help with debugging....)

[B Sleek]

Interesting approach. I'm a little scared about redesigning my base objects though. I'll have to carefully examine my design, to look for other approaches.

Thus, to "promote" an object, the underlying struct size would have to change. Java doesn't do this. Period. Could it? possibly. Is is necessarily a good idea? Maybe, but probably not.

I don't necessarily care if the structure changes...Why not just provide a way to create a NEW object with the values initialized to any base object, because the NEW structure will already have "room" for these values (class inherits structure). At this time you could just dispose the OLD object.

[Joel McNary]

unfortunately, that's not built-in. You would have to write that in you constructor yourself...

class Football(){
    public Football(Ball aBall){
        this.size = aBall.size;
        this.color = aBall.color;
        //etc...
    }
}

[Stan James]

However I am still struggling to see WHY the instance data belonging to my parent class can not be inherited to child objects.

That you absolutely can do. If Football extends Ball it has all the (non-private) member data and behavior that Ball had, plus "seams" or whatever else you want to add. In fact it's a nice rule that any code that works with Ball has to work with Football, so Football cannot leave anything out. The bit you can't do is morph an instance of Ball into an instance of Football.

It can be tricky and time consuming to turn a taxonomy of real world things into an inheritance tree. It can also paint you into a corner. Maybe you arranged the tree by shape and now you want to arrange it by inflatable vs solid balls or indoor vs outdoor sports. That's just a caution to invest carefully in intricate inheritance and consider aggregating separate objects instead. Some times inheritance is exactly what you need and some times it's not.

[William Brogden]

With the decorator pattern, your "wrapper" object INCLUDES the original instance of the base object, thus it automatically has access to the variables and methods thereof. Lets decorate the basic Ball object:

 
class Football{
 Ball theBall ;
 public Football( Ball baseBall){
  theBall = baseBall ;
 }
// add new functionality
 int seamCount ;
 public void setSeamCount( int n ){
  seamCount = n ;
 }
 // get to original Ball functionality
 // for each method in Ball you have a
 // pass-through method in Football
 public float weight(){ return theBall.getWeight() ; 
 }
 // etc.
}
 

Bill

[B Sleek]

Bill -

That looks promising. I will research the Decorator Pattern.

Thanks for everyone's help.