Enterprise Information Systems Patterns - Part VI

A DSL for Rules of Association
The use of rules of association may facilitate configuration: by querying them it is possible to check, for a given concept, which responsibilities can be assigned to it. The definition of a Domain Specific Language (DSL) for creating rules of association would be interesting, because it would allow the construction of more readable rules. In fact, a branch of should-dsl can be used. Should-DSL is a DSL for assertions, which are commonly used by coding techniques based on design by contract.

In fact, should-dsl's Predicate Matchers and some of the already available "ordinary" matchers such as respond_to,  which checks if an object has a given attribute or method, and be_instance_of, which verifies if an object is of a given type, can be used for formatting rules. For instance, let's suppose we have a decorator that is supposed to work only with persons:

class A_person_decorator:

    def __init__(decorated):
        ...
        #checks if decorated is compliant to the rules
        self.check_rules_of_association(decorated)
        #if it is compliant, sets a pointer to it
        self.decorated = decorated
        ...

    def check_rules_of_association(decorated):
        try:
            #uses be_instance_of matcher to check if decorated is compliant
            decorated |should| be_instance_of(Person)
        except:
            raise RuleOfAssociation('Person instance expected, instead %s passed' %  type(decorated))     
     
    ...

In the example above, type checking is necessary given the nature of Python language, however, the focus is in creating more complex rules related to the business rules.

Another interesting possibility is rule querying:
(i) For a given decorator, what are its rules of association (list its rules)?
(ii) For a given decorated, which decorators it can use (list which responsibilities a given class can assume)?
Query results could be presented in both human and machine readable ways. In other words, it would be some mechanism for querying rules, for both automatically checking associable objects in a object base, as well as informing people what is needed for configuring a concept to receive a given type of decoration.

A funny situation is that should-dsl matchers are used in unit tests to check the correct functioning of the rules... written in should-dsl.

The next post will describe some more details that decorators need to implement.