Hi,
Class extensions is at the core of the design of Moose. For example, for a class we have
as extensions:
- numberOfMethods
- isJUnit4TestCase
- viewBlueprint and viewBlueprintOn:
Now, the question is, when to extend an existing class and when not, given that it might
lead to a very large amount of methods. To answer this, let's start from the reason
for having the extensions in the first place.
We want extensions to unify the scripting and the user interface world. For example:
- if we are in a MooseFinder, we can see numberOfMethods in the properties pane, because
it is meta-described, and we can use it easily in scripting (each numberOfMethods >
10).
- The isJUnit4TestCase is not meta-described, but it's meant to be used as a query
facility.
- viewBlueprint appears in the menu and it is also meant to be used from the inspector.
- viewBlueprintOn: this is particularly useful when it is used inside other Mondrian or
Glamour scripts
So, all in all, you extend when you have:
- a meta-described property
- a query method (the best kind are unary ones)
- a menu entry
- a compose-able script
Now, when not to extend? Basically, when you do not fall in the above categories :).
Here are some examples:
- FAMIXClass>>viewMethods: aCollection inBlueprintLayerNamed: aString on: view
I can safely provide this as an example, because created it. This is a method that
basically only makes sense in the context of the class blueprint. So, it should be bundled
together in a separate helper class.
- FAMIXPackage>>configurationOfECell
This is basically just a helper method that only makes sense in the context of DSM, so it
should better be placed there.
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."