Is it code smell to make an abstract child class override a parent method which only calls its own abstract method

Question

Is it code smell to make an abstract child class implement a method, which overrides a parent method, whose only purpose is to call another abstract method? I want to make sure that anyone who implements my abstract class is aware that there needs to be special handling to override the functionality of a parent method. And making the parent method call my abstract method seems to be the best way to do that.

However it also feels redundant, someone could just override the parent method directly.

Here is some example code. It is totally contrived because I don't want to reveal what kind of code I'm actually working on. Please pay less attention to the example code because it may not be the best.

I'm wondering if this is ok? Or is it a symptom of code smell and I should re-work the code somehow.

<?php

abstract class Mammal {
    public function move() {
        // ... a bunch of complicated logic implementing common walk logic
    }
}


abstract class NonWalkingMammal extends Mammal {
    // Override the parent method to implement special handling defined by the abstract getMove() method.
    public function move() {
        return $this->getMove();
    }

    // NonWalkingMammals must implement logic for their movement
    abstract protected function getMove();
}

class Bat extends NonWalkingMammal {
    protected function getMove()
    {
         // ... flying logic
    }
}

class Whale extends NonWalkingMammal {
    protected function getMove()
    {
         // ... swimming logic
    }
}

Answer 1

I'm going to go with "yes"

It seems obvious from the need to completely replace the functionality in multiple classes that NonWalkingMammal should be the base class, then WalkingMammal can inherit and override with the walking logic. SwimmingMammal can make it swim etc etc

by switching things around you will improve your codebase.

Answer 2

The whole point of abstract methods is that they must, in general, be defined by the implementing class. Your entire implementation is to call another method, which is...OK, though not great as a general rule - unless maybe that code is used elsewhere. There are cases where the entire implementation of a method is to just call another method, but they tend to involve different method signatures using the same underlying implementation (e.g., adding to the end a collection and inserting to a collection).

In your contrived example (unless you post your actual code, this is what we have to go on), it serves no purpose whatsoever, and I wonder why you wouldn't just implement the swimming, flying, etc logic in the child class's move() method (it is appropriately named, after all, and not named something like walk() which is specific to walking mammals). If you're going to use the base class Mammal everywhere, your calling code won't even know of the existence of the getMove method on some of the child classes. Just leave it off and simplify.

Answer 3

If you need to enforce call order inheritance is not the way.

It will be super unobvious to people who fail to satisfy your invariants.

Try maybe doing a trick of returning special value from First method that's then mandatory argument on second method. In method body it would be ignored, but each callee would need to always call first method to even call second.