Extending the API

We have talked about the rule API regarding persistence-related rules and how to get information about problems with those. What more do we need of the API?

Well, depending on the application we are building, we might really need loads of other rules-related things. Inspired by the principles I started the chapter with, one thing that springs to mind is how nice it would be to be able to check for rules very proactively, especially when in the UI. Another important thing is to be able to add customized rules, not only at compile time but also at deployment time. Let's start with a look at consuming the rules in the UI.

Ask for Rules to Be Used to Set Up UI

I mentioned [Nilsson NED] that I wanted to reuse my rules from the logic layers in the user interface. Not duplicate, but reuse. Now is the time.

The approach I'm going to use here is to let the classes expose metadata that can be used by the UI if it wants to.

A similar approach is the one taken with Web Services that expose an XSD Schema, providing requirements on the data. I'm going for a slightly different approach to start off, providing lists of instances with similar information.

Note

Martin Fowler describes the problem in some detail [Fowler Fixed-LengthString]. He proposes a slightly different approach where an object for a string knows the maximum length on its own, for example.

Make It Possible to Inject Rules

It would be nice to be able to define rules on a case-by-case basis because some rules will obviously be very dependent on context.

Frequently, you want the customer to be able to add his own specific rules, and letting him do that isn't too hard if you create and expose a simple language for the customer to use to add rules.