Strategy pattern. Delegation vs inheritance

Hello everyone!
I assume that it is possible to implement strategy pattern with inheritance. So what is pros and cons of both ways?

@jrg.developer Can you please help with this when you get a chance? Thank you - much appreciated! :]

Thanks for your question, @observerward. :]

Yes, it is indeed possible to implement the strategy pattern with inheritance. You simply replace the strategy protocol with an “abstract” class instead. There are, of course, pros and cons to this approach:


  • A class can have stored properties, which a protocol cannot have.
  • A class can subclass another concrete class, which a protocol cannot do.


  • “Abstract” classes don’t actually exist in Swift/Objective-C/iOS. Consequently, it’s possible for a consumer to pass in an instance of the “abstract” type directly, which is perfectly legal from the compiler’s standpoint but basically guaranteed to cause problems at runtime.

  • Consumers are forced to subclass the “abstract” type, which may be difficult or impossible if an existing class already subclasses another type. There are other patterns that help with this – see Adapter for example – but it just make things a bit more difficult, perhaps unnecessarily.

With these limitations in mind, you might wonder, “Should I always prefer protocols, then?” Not necessarily.

I generally would prefer protocols over classes for implementing the strategy pattern, but at times, it’s either not feasible or much harder. For example, if your strategy requires a lot of properties, or you’re required to subclass an Objective-C class (such as interacting with legacy and/or Apple code), then you may be better off using an “abstract” class than a protocol.

As with most programming problems, the final answer really depends on the details! Analyze your situation, and make good choices. :wink:

I hope this answer helps. If you need more clarity here, let me know. :]

Oh, thank you for explanation!