in reply to Re: Re: Re: Re: Re: OOP - Sharing class methods
in thread OOP - Sharing class methods

Suppose you want to subclass Foo to use a different UtilityClass

Well, if that happened, and there was nothing else in the subclass that would cause me to override these methods, then I would do what you've suggested. However, that's a pretty unlikely scenario and I don't see any reason to add the extra complexity until it's actually needed. My opinion is that the code should stay as simple as possible until the requirements demand it be more complex.

I've also seen this sort of technique used for runtime configuration (e.g. use Storable or Data::Dumper for serialization), but that doesn't seem to be called for here.

Replies are listed 'Best First'.
Re: hard-coding class names
by pdcawley (Hermit) on Aug 16, 2002 at 09:38 UTC
    Ah. I must confess that I don't really think of the first of those methods as adding complexity so much as reducing repetition and adding simplicity. I've got caught out by hardcoded class names in projects before so now it's almost a reflex to fetch them dynamically.

    Actually, my usual issue with hardcoded classnames is that it makes using 'mock object' techniques that much harder, but the very lovely Test::MockObject makes working 'round that particular issue a lot easier now.