How to apply design patterns in this scenario

How accurate this advice is may vary, over on StackOverflow someone stated: "Be wary of Design Patterns; learning a Pattern may inhibit your ability to correctly implement the proper design. This can cause bad developer habits and practices."

Which does make sense; as your bending your application to a pattern rather the pattern to your application. Which is essentially like a cookie-cutter approach.

However...

Codeplex has some great tutorials on Dependency Injection, Repository, Unit Of Work. Plus Amazon has some great books out there as well. Microsoft has a free architecture handbook which is very solid also. The Stack Overflow post has a link to that manual, but here is a direct link.

A pattern you may want to look into is SOA(Service Oriented Architecture). It is looked at as an Anti-Pattern, but with the culmination of Windows Communication Service and abstraction. It can provide a very agile lightweight flexible solution. Assuming your application benefits from this approach.

• Service Oriented Architecture
• ORM
• Dependency Injection
• Repository Pattern
• N-Tier Applications

Those are few sites with good details; hopefully that is helpful. There is a lot to learn; but the simplest solution is usually the right solution.

I had a bunch of links; but my rep is too low on this site to post em. Just Google those terms and you should get some nice articles.

You have created your own, unnecessary problem here.

1. Everything must be runnable
2. The default implementation of run requires proc
3. Anybody implementing their own run can ignore proc (but all that useless code still adorns the class and any descendants).
4. Your concrete, exception-throwing implementation of proc enables people to set up themselves up for runtime errors. Why do that?

OK, so you wanted to be helpful by providing a default implementation but you have bolted on implementation details which you know will not always be desired. You say you want to avoid code duplication but you have encumbered your hierarchy with code which will be obsolete as soon as somebody extends it.

I would strongly urge you to go the interface/abstract-base-class route here:

1. Abstract base class runnable
2. Abstract base class proccer
3. Create proc-calling concrete implementation of runnable.
4. Wherever possible (even in proc-caller class methods) refer to runnables and not proc-callers).

So your default run implentation can be used where desired but can be dropped without penalty. Also, this way people are forced to implement proc if they mix in proc-caller but you don't have to write that "Not implemented" version of proc - they can't compile their code if they do not implement proc. Why create that runtime trap when you can require them to fix things at compile time?

If you think there are other useful behaviours which should be available, you can avoid code duplication by providing "interfaces" in the same way I have shown for proc. Anybody who wants that can mix it in.