XP is just a number | |
PerlMonks |
Re: Modification of @ISA at run timeby nothingmuch (Priest) |
on Sep 01, 2005 at 07:04 UTC ( [id://488313]=note: print w/replies, xml ) | Need Help?? |
My solution is always to deglobalize.
If $sun_rises_in_west is a global condition, encapsulate it. Sometimes you want to calculate things for the parallel universe you don't live in. What is your user going to do then? To emulate global behavior, just make your default instantiation take into account the fact that the default $sun_rises_in_west_flag is x and not y, and save it as instance data. To dispatch based on instance data, the most useful technique is delegation - encapsulate your instance data in an object, and have your object as that object to polymorphically get_sunrise_time based on the kind of object it is. Playing with multiple inheritence implies that your object hierarchy is not only a definition, it also encapsulates state. While this feels very cool and meta-meta-meta-fun, it's usually not very good for:
Update: blazar requrested that I added an example, based on TheDamian's reply..
The difference between this and the factory approach is not very evident at this scale. This has some disadvantages, namely in being a harder to set up, and less efficient, but it scales better when you have several variadic sets of methods... For example, if $sun_rises_in_west and $number_of_moons > 1, and so on, it might be easier to make a delegate for each, instead of combining each possibility into it's own class. Update 2: I should mention what I really like about delegates - they allow you to keep things better separated. Instead of your entire set of capabilities (methods) being mushed into one object, you get a higher degree of separation. Whether this boundry is later blurred for convenience as far as code using the delegating object is concerned is irrelevant - the implementation of the delegating object stays cleaner. This is useful when you have conceptual objects that perform many roles. For example, I have a system where data can be used as resources in a resource allocator. Instead of making the data, which already has the mess involved with persistence and what not added in, inherit yet another class (the one for a resource), i simply make a new resource class, that is a thin wrapper around this object. This object then becomes a delegate of the resource class. This has a conceptual simiarity to the MVC model. The model part shows you what the is structured like. The control decides what to do with the data, andn the view, through the controller, displays the model. The delegating object is a bit like a controller, and the delegate is a bit like a model in this sense.
-nuffin zz zZ Z Z #!perl
In Section
Seekers of Perl Wisdom
|
|