Well, the reimplementation of isa is probably the way to go, but normally I've found that the greater the all-knowingness of an object, the less I need to introspect it.
In a sense the behavior is transparent, instead of using a delegate there could have been an if/else on the member data in the single classes get_sunrise_time
My point is that when designing in this direction, usually you want to pretend that the object is the same, and the delegate is just an implementation detail. In situations when the role is truely different you don't want to instantiate from the same class anyway, you have have two top level classes, one for west-rising suns, and the other for east rising ones.
In fact, that is exactly what the delegation model is - it's two independant classes, completely unbound to each other, but interchangable, and an object which can reuse them to give you an alternative with a single point of entry.
Good examples of this kind of reuse can be dug up by querying Any... These are modules which usually wrap around several modules which do the same role, but have different features. The wrapper modules hide the details of the difference from the user, letting the user give the generic module more kinds of input, without caring which bunch of code really does the job at the end.
To wit, after saying
my $a = Archive::Any->new($archive_file);
I don't care if what I got was reblessed into a different class, or wheter it has a delegate, or whether it uses MMD inside. In fact, it probably isn't Archive::Tar at all, in any sense, since it doesn't provide it's full interface.
When ->isa checks are used with respect to the delegate for the prupose of type checking (what kind of archive format do you encapsulate, mr Archive::Any instance?), then it's perhaps a design problem, because not caring is the reason we wrapped it in the first place.
| [reply]
[d/l]
[select] |
When ->isa checks are used with respect to the delegate for the prupose of type checking (what kind of archive format do you encapsulate, mr Archive::Any instance?), then it's perhaps a design problem, because not caring is the reason we wrapped it in the first place.
But one may find desirable to have some common functionality plus extra type-specific features, e.g.
if ($this->isa 'cool_archive') {
print $this->name, " is a cool archive.\n", <<EOT;
You also have the following cool features:
... (more cool features)
EOT
# interactively ask user to pick one...
}
Or is such a design to be considered inherently risky? | [reply]
[d/l] |
This example is not well suited for a delegator model, but for a factory one, where each class presents it's routines to the routine displayer code (polymorphically, too - the code that has these archive plugins shouldn't care, it should only handle the interactivity).
The open archive command takes a CLI, and dispatches to a factory constructor, that chooses the right class, and then the instance of this class is presented to the user with the enumerated options, extracted metadata, and so forth.
| [reply] |