I have found a similar construct useful in the context of a related class hierarchy, where an object turns itself into an object further down the inheritence chain. An example is this: You have a base file class. The constructor of that class takes a file name and provides back an object representing that file. Now suppose you have a subclass for directories. If you want to maintain a simple file name contract with the outside world, you could have the base file class figure out if the given file name is actually a directory and pass back an object of the derived directory class if it is.

I've had similar interfaces where the decision can't be made at construction time. In the file example, maybe you first have an object representing a remote file on another system, but it's not until some connect method that more details of that object are filled in and you realize the remote file is actually a directory. I've morphed objects into objects of derived classes in cases like that by reblessing them.

I don't consider this bad coding practice since you've maintained the contract, at least in a loose sense: The object is still a file, it's just a more specific kind of file. There are obvious flaws in this design, but in some cases I've found it to be the best choice, given that any approach has flaws.