• Post Reply Bookmark Topic Watch Topic
  • New Topic

OOP Object Construction  RSS feed

 
B Sleek
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


[ December 13, 2004: Message edited by: B Sleek ]
 
Stefan Krompass
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



And then you get your Football by calling:

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:



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


Add in the exception handling, and you're done!
[ December 13, 2004: Message edited by: Joel McNary ]
 
B Sleek
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
B Sleek
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
unfortunately, that's not built-in. You would have to write that in you constructor yourself...
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:


Bill
 
B Sleek
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bill -

That looks promising. I will research the Decorator Pattern.

Thanks for everyone's help.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!