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

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]