The framework can't know exactly what your rules are but the framework can deal with the broken ones in a standard way. It can display a standard error message or display the controls that violated the rules with an error next to them. If you move your middle tier to the web it can reuse those rules.

I think you know all this already. You still have to subclass and create methods or logic for each of your rules.

So far, the level of abstaction has been to populate a collection of broken rules. Would there be a benefit to creating a Rule class that has some specialized behavior so that instead of each rule being a method each rule would be an object? Maybe, but I can't think of a good reason. Maybe to store the rules in a database table?

So actually the answer is that no, the individual *rules* themselves aren't abstract at all. Each one is a separate concrete method. In fact this is a case where encapsulation has been broken to make things easier. The pure OOP way would be to create an abstract Rule class but then you would have to create a subclass for each rule! The framework doesn't prevent you from doing this yourself but that would suck.<g> (Almost forgot to grin)

>>Abstraction provides all the benefits to the programmer.
>
>And in the specific context of this discussion (abstraction of business rules where the business rules are unknown), what are some specifc examples of those benefits?
>
>This was the first question I posted in this thread. While we've since talked about how the framework was developed and how flexibility is key, I still haven't gotten an answer to the question I'm actually interested in.