Calling Methods of Super Classes

I was running quickly through the list of my subscriptions when one post by Martin Fowler attracted my attention. Martin is famous in OOP world for his knowledge and experience in design and development of applications. Indeed, he has a lot of great publications (books and articles), he attended many conferences and wrote a lot of wonderful software. What am I talking about? Ah, the article… yes, in his article he tells us how badly smells the calling of methods of super class. I wouldn’t have believed, If only I hadn’t seen that with my own eyes. Excuse me, Mr. Fowler, but I can’t agree with you, completely…

Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck and others Design Patterns by Erich Gamma

Martin insists that writing methods, which are making calls to super classes, like below, is dangerous and smells bad.

public void handle(BankingEvent e) {

He says that one can possibly forget to call super class method before doing his own processing and that can be dangerous. Yes, I agree that there’s nothing good about it. He provides the alternative approach using hooks. Above example, modified with hooks, can look like this:

public void handle (BankingEvent e) {
protected void doHandle(BankingEvent e) { }

What I can’t agree with under any condition is that it’s convenient to put hooks everywhere. When we were using calls to super methods we were free to position this call everywhere – before our own processing, after our processing and even skip super calls, depending on what behavior we would like to achieve With hooks, we need something like this:

public void handle (BankingEvent e) {
if (beforeHandle(e))
protected boolean beforeHandle(BankingEvent e) { return ...; }
protected void afterHandle(BankingEvent e) { }

And the following picture is required for every method we would like to “protect” from programmer, forgetting to call super methods!

People, I encourage you to turn on your brains!

I don’t know what Martin is/was thinking about, but this particular “smell” really smells badly! Use hooks when the hooks are required to adjust the functionality and you know that someone will need to do that and will not be trivial overriding of the method. Hooks are very useful to make injections in your code and I’m sure that you use this widely in your creations. Just look at the sample below and you will see what I mean:

public abstract class DataFeed {
public void update() {
try {
FeedData feedData = fetchData();
} catch (...) {}

protected abstract FeedData fetchData();

The hook fetchData() has clear intention and positioned accordingly inside the update() method of super. This behavior cannot be accomplished with overriding update() method. I call it correct use of hook – you just provide a clear and simple means to inject custom functionality. If one needs to do something before or after or instead of this base update functionality he may wish to override the method update() and adjust it appropriately.

Turn on your brains and filter information! Don’t believe it blindly!