An idea for Composite Specifications

Several days ago I've written some blog posts about how to work with and implement Specifications.

In particular, I've written one article about how to implement Specifications with Apache Commons Collections.
For a short recalling, we implemented Specifications using Commons Predicate as base interface, which let us combine those specifications using Commons PredicateUtils class.
This approach has two main disadvantages:

• Force you to use the Commons Predicate interface which, for example, is not generics-enabled


• Give you a flexibility limited by Commons PredicateUtils capabilities.

What about using a generic composite specification, capable of combining general specifications using logical operators, with a fluent-style interface?

Let us suddenly go with a simple example.

Take one office interface:

public interface IOffice {

    void setOfficeId(String officeId);

    String getOfficeId();
    
    void addEmployee(IEmployee e);
    
    Set getEmployees();
}

Take one employee interface:

public interface IEmployee extends Serializable {

    void setMatriculationCode(String matriculationCode);
    
    String getMatriculationCode();
}

You can create offices and add employees to them, but your boss said you have some business rules:

• Every office id must begin with the "o" letter, and follow with numbers.


• You cannot have an office with more than three employees.

Say you want to implement those rules as Specifications (remember, this is an oversimplified example).
Here are your specifications:

/**
 * A generics-enabled specification interface.
 */
public interface Specification<T> {
    public Boolean isSatisfiedBy(T object);
}

/**
 * A specification for the office id.
 */
public class OfficeIdSpecification 
implements Specification<IOffice> {   
    public Boolean isSatisfiedBy(IOffice o) {
        return o.getOfficeId().matches("o\\d+"); 
    }
}

/**
 * A specification for the office room availability, determining
 * if an office is full.
 */
public class FullOfficeSpecification 
implements Specification<IOffice> {
    
    private int limit = 3;
    
    public Boolean isSatisfiedBy(IOffice o) {
        return o.getEmployees().size() > this.limit; 
    }
}

And ... here is how would be our composite specification:

public class CompositeSpecification<T> {
    
    public CompositeSpecification(Class<T> specificationClass, 
                                  String specificationMethod, 
                                  Class specificationObjectClass) {
        // ...
    }
    
    public CompositeSpecification compose(T specification) {
        // ...
    }
    
    public CompositeSpecification and(T specification) {
        // ...
    }
    
    public CompositeSpecification or(T specification) {
        // ...
    }
    
    public CompositeSpecification and(CompositeSpecification<T> specification) {
        // ...
    }
    
    public CompositeSpecification or(CompositeSpecification<T> specification) {
        // ...
    }
    
    public CompositeSpecification andNot(T specification) {
        // ...
    }
    
    public CompositeSpecification orNot(T specification) {
        // ...
    }
    
    public CompositeSpecification andNot(CompositeSpecification<T> specification) {
        // ...
    }
    
    public CompositeSpecification orNot(CompositeSpecification<T> specification) {
        // ...
    }
    
    public CompositeSpecification not() {
        // ...
    }

    public boolean evaluate(Object object) {
      // ...
    }
}

I intentionally omitted implementation details because at the moment I'd like to point you out:

• The generics-enabled interface, which let you specify your own specification to combine.


• The constructor, where you have to describe the actual specification you'll combine, specifying its class, its specification method (isSatisfiedBy in our example) and the class of the specification object (IOffice in our example).


• The fluent-style interface methods for applying logical operators to actual specifications or other composite specifications.

Here is an example about how to use such a class:

CompositeSpecification<Specification> compositeSpecification = 
  new CompositeSpecification<Specification>(Specification.class, 
                                                  "isSatisfiedBy", 
                                                  IOffice.class);

OfficeIdSpecification spec1 = new OfficeIdSpecification();
FullOfficeSpecification spec2 = new FullOfficeSpecification();

IOffice office1 = new Office();
IEmployee emp1 = new Employee();

office1.setOfficeId("o1");
emp1.setMatriculationCode("1");
office1.addEmployee(emp1);

// The office has a valid id and is not full:
assertTrue(compositeSpecification.compose(spec1).andNot(spec2).evaluate(office1));

I'll discuss implementation details in another post.
But for now, what do you think about this approach?

Updates:
04/05/2006 : Fixes in code.