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.
In reply to Re (tilly) 2: change object class during runtime
by tilly
in thread change object class during runtime
by busunsl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |