it’s easier to refactor into an inheritance hierarchy from interfaces than to refactor to interfaces from an inheritance hierarchy..

i’m slowly becoming less and less of a fan of layer supertypes..

the other thing that jumped out at me was that interfaces represent a CAN DO relationship (which popped on a light bulb for me).. shortly thereafter i refactored the security roles and permissions of our app to support a new interface IAssertable.. ;-)

I have a new and very long post coming out today on how to get implement a POCO template method using generics in response to Evan’s comment above about violating SRP/OCP. I’d be interested in your feedback on that.

create an interface IExecutable with one method, Execute()

then build a class for each technical concern (logging, transactions, security, eventing aka observation, caching)..

each of the classes can implement IExecutable and take another IExecutable in their constructor..it’s a simple way to layer each on top while keeping true to the single responsibility and open/closed principles..each class performs its responsibility and then delegates to the next object (passed into the constructor) until the final object gets executed (the real Task object).. it gives you the freedom to change one technical concern without affecting the others..or providing multiple implementations of a particular concern (ie..two caching modes). you can also apply some concerns to some tasks while leaving others off (or rearranging the order of execution).. you can think of them as mini-layers on top of your task object (which also implements IExecutable)

you can either wire the whole thing up with a DI container or create a factory to add the objects onto the task objects (depending on the app)