We initially wanted to implement a Strategy pattern with varying implementations of the methods in a commmon interface. These will get picked up at runtime based on user inputs.

As it's turned out, we're having Abstract classes implementing 3 - 5 common methods and only one method left for a varying implementation i.e. the Strategy.

Update: By many abstract classes I mean there are 6 different high level functionalities i.e. 6 packages , and each has it's Interface + AbstractImpl + (series of Actual Impl).

Is this a bad design in any way?

Any negative views in terms of later extensibility - I'm preparing for a code/design review with seniors.

4 Answers 4


No, this is by no means a bad design. It's a template method pattern.

It's meant to encapsulate the varying behaviour of an algorithm step, which is probably the case in your scenario. Strategy and template method patterns make a strong combination in many cases. You probably have abstract strategies as a frame and the use the template method pattern for concrete strategies. That's pretty clean.

It's extensible and also you don't need to repeat code. When you need something entirely different, just use the strategy interface to create a new abstract or concrete strategy.


No, it can be quite OK (depending on the details - it is hard to say more with this little knowledge about your concrete case). It is perfectly fine to unify common method implementations in an abstract base class.

Depending on how the single abstract method is used in your classes, this pattern might be a Template method rather than Strategy though. Namely, if it is called by some other, final method in the base class, rather than directly by the external world.


Template Method Patterns make subclass to implement special code by abstract method and the subclass inherits common method from superclass. So i do not think this has many Abstract classes, it is only one Abstract classes, all subclass is instance class.


If the abstract classes are implimenting the same methods, with the same content then why have multiple abstract classes?

If they are implimenting the methods differently then I don't see a problem.

To improve extensibility use interfaces, then it is less of a problem if you then scrap the abstract class(es)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.