(tye)Re: change object class during runtime

Inheritance should really be a last resort. Have a "connection" object that contains an object that is server-specific. When there is no valid connect, the connection object contains an undef for the server-specific object. When the connection comes up, create a new contained object specific to the type of server found.

Then have the connection object dispatch to the server-specific code. Don't let the connection object hand out references to the server-specific object otherwise you have problems trying to change it out from under people.

Now, if Perl had (native) interface inheritance, then it might be worth making a virtual class to define the interface of these server-specific objects so that they'd be forced to share the same core interface.

If there is likely to be shared code among several of the server-specific objects, then inheritance probably makes sense. Also, you could have the base class for the server-specific objects be the "no server" object that just pukes (very nicely, of course) if you try to do something that can only be done when the server is up.

I'd be very reluctant to write production code that reblesses objects. It just seems sloppy and so likely to run into some nasty problems down the road. Especially in this case where you have connection methods that don't change (can't change) based on the server type and other methods that must change. Those groups of methods should be separated into different classes in the hopes of making maintenance easier.

For example, you want to be able to make the object constructor different for each server-specific object in case some server types require different member data to be tracked. If you go reblessing an object after it is created, then you can't rely on the constructor to have set up the object properly any more and have to duplicate code to handle any changes required during reblessing. So instead of N constructors, you could end up with N constructors and N*(N-1) reblessing cases to maintain! Ugly!

- tye (but my friends call me "Tye")

Comment on (tye)Re: change object class during runtime

Replies are listed 'Best First'.
Re (tilly) 2: change object class during runtime by tilly (Archbishop) on Jun 19, 2001 at 20:26 UTC
I would not be at all reluctant to write production code that reblesses objects. I wouldn't even consider doing so unless a good chunk of the component was designed around that idea. But if, for instance, a good chunk of my system was a "state diagram" with the current state indicated by the current class, then I would be perfectly willing to proceed. In the abstract I think that would be perfectly maintainable. Certainly it is a design pattern that fits with a circle of ideas which I know are both natural and maintainable for certain classes of problems. The practical implementation may be a different matter, but my sense is not against it. That said, I have never actually needed that design. Nor would I encourage casually experimenting with it in production code just to see how it works - most times it would be a horrible fit for sanity and in this case I would definitely go with your proxy idea. But still, unless the concept of "state transitions" is utterly essential to how you are thinking about your functioning system, I wouldn't rebless.	[reply]

Replies are listed 'Best First'.

Re (tilly) 2: change object class during runtime
by tilly (Archbishop) on Jun 19, 2001 at 20:26 UTC

I wouldn't even consider doing so unless a good chunk of the component was designed around that idea. But if, for instance, a good chunk of my system was a "state diagram" with the current state indicated by the current class, then I would be perfectly willing to proceed.

In the abstract I think that would be perfectly maintainable. Certainly it is a design pattern that fits with a circle of ideas which I know are both natural and maintainable for certain classes of problems. The practical implementation may be a different matter, but my sense is not against it.

That said, I have never actually needed that design. Nor would I encourage casually experimenting with it in production code just to see how it works - most times it would be a horrible fit for sanity and in this case I would definitely go with your proxy idea.

But still, unless the concept of "state transitions" is utterly essential to how you are thinking about your functioning system, I wouldn't rebless.

[reply]