Architecting common and unique behaviour in code

Question

I am designing a utility to backup applications.

The backup functionality will contain both common tasks to do (common code) and some unique steps. Am I on the right track by using an interface for the unique behaviour and an abstract base class for the common behaviour in common by all the children? Is there any downside to this approach? Anything better?

Thanks

Answer 1

If the base class actually implements some behaviour then I think it's called a non-abstract base class.

Anyway I think that's called Template method pattern: you may want to look that up in a dictionary of patterns (which should explain when it's appropriate, and reference any similar alternative patterns).

Answer 2

I wouldn't use abstract base classes to share common functionality, but only to express is-a relationships. If D derives from B, wherever B is expected, a D can come up. This is the criteria for using public inheritance.

You can use private inheritance though, but you are limited to derive from only one class in some languages.

Which brings us to the point to should be the first - you should think about responsibilites and encapsulate functionality wherever it belongs to, exposing interfaces (or pure abstract classes in C++) to clients, and implementing functionalities in concrete classes that derive from those interfaces.