We have a consistency checker class, and an instance of it is injected into the controller. This class is used to check the consistency, but it does not actually perform the check itself. It only controls the different checkers that we provide and invokes them one by one to do the real work.

We require that a consistency checker, such as the one that checks whether the order contains a power cord when a desk-side lamp is ordered, implements the ConsistencyChecker interface:

package packt.java9.by.example.mybusiness.bulkorder; 

import ... 
public interface ConsistencyChecker { 
    boolean isInconsistent(Order order); 
}

The method isInconsistent should return true if the order is inconsistent. It returns false if it does not know whether the order is inconsistent or not, but from the aspect that the actual checker examines the order, there is no inconsistency. Having several ConsistencyChecker classes, we have to invoke one after the other until one returns true or we are out of them. If none of them returns true, then we can safely assume, at least from the automated checkers' point of view, that the order is consistent.

We know at the start of the development that we will really have a lot of consistency checkers and not all are relevant for all of the orders. We want to avoid the invocation of each checker for each order. To do so, we implement some filtering. We let products specify what type of checks they need. This is a piece of product information, such as the size or the description. To accommodate this, we need to extend the ProductInformation class.

We will create each ConsistencyChecker interface, implementing the class to be a Spring bean (annotated with the @Component annotation), and at the same time, we will annotate them with an annotation that specifies what type of checks they implement. At the same time, ProductInformation is extended, containing a set of Annotation class objects that specify which checkers to invoke. We could simply list the checker classes instead of the annotations, but this gives us some extra freedom in configuring the mapping between the products and the annotations. The annotation specifies the type of the products, and the checker classes are annotated. The desk-side lamp has the PoweredDevice type, and the checker class, NeedPowercord, is annotated with the @PoweredDevice annotation. If there is any other type of products that also needs a power cord, then the annotation of that type should be added to the NeedPowercord class, and our code will work. Since we start diving deep into annotations and annotation handling, we have to first learn what annotations really are. We have already used annotations since Chapter 3, Optimizing the Sort, Making Code Professional but all we knew was how to use them, and that is usually dangerous without understanding what we did.