Implementing methods in a subclass or providing in-place callback: Is it overengineered?

Dallaylaen has asked for the wisdom of the Perl Monks concerning the following question:

Hello, dear esteemed monks!

I just wrote the following in my module. The idea is as follows: allow user to override default methods by either subclassing, or providing a callback. So a subclass with do_foo method and an instance of base class with on_foo member will behave exactly the same.

However, looking at this again, I suspect it's being overengineered. Should I just provide default do_foo methods in subclass that search for a callback and croak if none found? This will still allow for both ad-hoc overriding and subclassing.

Should I just go with normal OO and leave do_foo() alone?

Guess there's no single correct answer after all, but I'd like to hear your opinions and make up my own.

sub backend_call {
    my $self = shift;
    my $method = shift;

    my $todo = $self->{"on_$method"} || $self->can("do_$method");
    if (!$todo) {
        my $sub = [caller(1)]->[3];
        $sub =~ s/.*:://;
        croak join "", (ref $self || $self),"->",$sub,
            ": no backend found for $method";
    };

    return $todo->($self, @_);
};
[download]

Thank you!

Comment on Implementing methods in a subclass or providing in-place callback: Is it overengineered? Download Code

Replies are listed 'Best First'.
Re: Implementing methods in a subclass or providing in-place callback: Is it overengineered? by haukex (Archbishop) on Sep 23, 2016 at 09:51 UTC
Hi Dallaylaen, I would base this decision on how the module is actually being used. I'd start with just normal OO subclassing, and then start writing real code that uses the module. If I then discover that I have a need to expand the module, for example I have a real use case for the callback mechanism you described, that's when I'd add that. If you don't yet have code that uses your module, that's what I'd recommend doing next :-) Regards, -- Hauke D	[reply]
Re^2: Implementing methods in a subclass or providing in-place callback: Is it overengineered? by Dallaylaen (Chaplain) on Sep 23, 2016 at 18:03 UTC
Thank you, Hauke D. I ended up rethinking that part altogether and moving method implementation (i.e. the do_foo()) part into a separate class (aka strategy pattern). Should I really want to provide in-place callbacks, I can always write an in-place package with only needed methods overridden. Actually already did it for the test. I was doing it wrong. At least a bad decision was caught before it became hard to remove.	[reply]
Re: Implementing methods in a subclass or providing in-place callback: Is it overengineered? by BrowserUk (Patriarch) on Sep 23, 2016 at 12:27 UTC
Without having read anything more than the title of your post, the very fact that you are asking the question, pretty much guarantees that the answer is yes. If it -- whatever it is -- was a requirement or necessity, then you wouldn't be thinking the question, much less asking it here, so that means you have or are considering implementing a piece of "wouldn't it be cool if" code, and that is over-engineering by definition. Whether that is of itself a bad thing, depends entirely upon the costs of your design decision; and you probably won't know those until your code has been in production, or at least regular use for a good while, and it will be too late to rescind it. Bottom line: think carefully about providing 'optional extras'; they always have associated costs. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]


Keep It Simple, Stupid
	PerlMonks