Properly implementing Polymorphism

ServerStorm · January 13, 2012, 9:42pm

Michael_Morris:

You shouldn’t need to produce empty placeholder methods which may never need to be populated. It just doesn’t look right. Also, there is a break between the external facing API and the internal API. For example, going back to the original example…
[…]
The former method, the one I label as incorrect, allows for 2 possible hook points and 2 functions which may remain unused. The later method allows for 6 hook points overall, though effectively 4 hooks since there is no operative difference between hooking in at the end of precommit and hooking to the start of commit.

More important than the choice to do hooks or not is this - the more your function does, the more likely you will need to alter the course of its operation in the future. That’s the primary reason to keep the scope of the function small. The same applies to classes - the larger they are the more likely they will need modification.

Avoiding hooks encourages code granularity. Polymorphism, whether achieved through inheritance or by composition, needs the elements of the code to be as granular as possible.

Excellent, thanks for your efforts as your thread intention is now very clear to me and hopeful for others too!

ServerStorm · January 13, 2012, 9:47pm

@guido2004
Maybe we should start a new thread with an example/description of object composition with comments of when to choose over inheritance and then link the inheritance to this thread. Thoughts?

DarthGuido · January 13, 2012, 9:52pm

Yes, much clearer. Thanks Michael.

DarthGuido · January 13, 2012, 9:56pm

Yes, I guess that’s a good idea. The scope of threads is best kept small as well

Jake_Arkinstall · January 14, 2012, 5:51am

Thanks ServerStorm, it seems the forum is less paste-friendly than I remember it! Should have looked at the post before closing the window

The code I wrote above is essentially a way of inserting added functionality into a method. For example, a method whch has ten steps may very often have those steps in all child classes but maybe adding a method call in somewhere inbetween other calls - it allows you to jump in the middle of functionality without repeating the same call steps in every child class methods.

It was purely theoretical and anyone who would actually use it would be downright insane. Just seeing what I could come up with (Probably habit from the old Application Design forum where each reply to an idea generally expanded it, made it more complicate and, as a payoff, ever so slightly more flexible to the point of pointlessness. Im going to miss that forum.)

It is.essentially, to break it down, an object which holds an array of methods to use. Thy are run in any order so long as the methods can be run, I.e. the appropriate preceding methods have been run. If you’d like to, for exmple, extend a mapper such tht an email is sent after data is processed but before it is saved, you could modify the “save” object’s tasks to make your email method run after the processing method, and modify the db-calling method to run after the emailing method. Its only real-life use would be in a system where
the parent classes are subject to massive frequent changes.

Nicely rounded off Michael, I believe youve explained your point very well.

Apologies for typography errors, this was written via a mobile phone, and the browser doesnt seem to handle this textarea nicely at all.

ServerStorm · January 16, 2012, 3:13pm

Jake_Arkinstall:

Thanks ServerStorm, it seems the forum is less paste-friendly than I remember it! Should have looked at the post before closing the window

The code I wrote above is essentially a way of inserting added functionality into a method. For example, a method whch has ten steps may very often have those steps in all child classes but maybe adding a method call in somewhere inbetween other calls - it allows you to jump in the middle of functionality without repeating the same call steps in every child class methods.

It was purely theoretical and anyone who would actually use it would be downright insane. Just seeing what I could come up with (Probably habit from the old Application Design forum where each reply to an idea generally expanded it, made it more complicate and, as a payoff, ever so slightly more flexible to the point of pointlessness. Im going to miss that forum.)

It is.essentially, to break it down, an object which holds an array of methods to use. Thy are run in any order so long as the methods can be run, I.e. the appropriate preceding methods have been run. If you’d like to, for exmple, extend a mapper such tht an email is sent after data is processed but before it is saved, you could modify the “save” object’s tasks to make your email method run after the processing method, and modify the db-calling method to run after the emailing method. Its only real-life use would be in a system where
the parent classes are subject to massive frequent changes.

Nicely rounded off Michael, I believe youve explained your point very well.

Apologies for typography errors, this was written via a mobile phone, and the browser doesnt seem to handle this textarea nicely at all.

Thanks for the clarification @Jake Arkinstall. To your comment

It was purely theoretical and anyone who would actually use it would be downright insane. Just seeing what I could come up with (Probably habit from the old Application Design forum where each reply to an idea generally expanded it, made it more complicate and, as a payoff, ever so slightly more flexible to the point of pointlessness. Im going to miss that forum.)
Most of the people that made the old Application Design Form have left or are very infrequent. People posting in the form had at times became stranded. A long long time ago LastCraft and other argued that breaking the OOP/ Application Design into two streams would eventually cause the death of the OOP based forum - they were right or professed a manifest destiny; in any case there is room for such discussion and extension in this merged forum, it will take a little while for this to get organized as the ‘new’ order as well as the ‘die hards’ will participate in this process. Hopefully you will stay and contribute as you used to do as your input is valuable!

Regards,
Steve