>I'm still missing it. What value would these "abstract" classes have that the "concrete" ones don't have? Why can't I use the "concrete" classes as "blueprints"?

David Frankenbach put it very nicely in a reply to you today in this same thread.

I couldn't put it better, so I'll quote him here:

* give this class an Execute() method - this is an abstract method, it is a method that every subclass will have in it's interface, but there is no code here at the level, because you don't yet have a clue about what this business process is really going to accomplish. But you've established the interface, you've established that anyone can call the Execute() to get the object to do its thing.


Clearer now? You define what the method is for, the interface, etc.
But it will be really usable once you know the business rules or needs for that particular instance in your project. That's when you do the concrete method (instance).

HTH