Interpreter Pattern in Java

Today i was reading "Refactoring to Patterns" book written by Joshua Kerievsky.

I want to share "Replace Implicit Language with Interpreter" section written in the book in this blog article.

Intent:
Define classes for elements of the implicit language so that instances may be combined to form interpretable expressions.

Motivation:-

An Interpreter [DP] is useful for interpreting simple languages. A simple language is one that has a grammar that may be modeled using a small number of classes. Sentences and expressions in simple languages are formed by combining instances of the grammar's classes, typically using a Composite [DP] structure.

Frankly,we donot need an interpreter for really simple ones.

Typical searches require the use of words like "and," "not," and "or" (called nonterminal expressions), as well as values like "$10.00," "small," and "blue" (called terminal expressions). For example:

Find products below £10.00.

Find products below £10.00 and not white.

Find products that are blue, small, and below £20.00.

Such search expressions are often programmed into systems without using an explicit language. Consider this class:

ProductFinder...
   public List byColor(Color colorOfProductToFind)...
   public List byPrice(float priceLimit)...
   public List bySize(int sizeToFind)...
   public List belowPrice(float price) ...
   public List belowPriceAvoidingAColor(float price)...
   public List byColorAndBelowPrice(Color color, float price)...
   public List byColorSizeAndBelowPrice(Color color, int size, float price)...

Programmed in this way, a product-finding language is implicit: present, but unexpressed. Two problems result from this approach. First, you must create a new method for each new combination of product criteria. Second, the product-finding methods tend to duplicate a lot of product-finding code. An Interpreter solution is better because it can support a large variety of product queries with a little over a half-dozen small classes and no duplication of code.

Benefits and Liabilities

+ Supports Combinations of Language elements better than implicit language does.

+ Requires no new code to support new combinations.

+ Allows for runtime configuration of behavior.

- Complicates a design.

Example:

Let's begin by studying the tests and code for a ProductFinder that is in need of this refactoring. We'll start with the test code. Before any test can run, we need a ProductRepository object that's filled with various Product objects and a ProductFinder object that knows about the ProductRepository:

public class ProductFinderTests extends TestCase...
   private ProductFinder finder;

   private Product fireTruck =
      new Product("f1234", "Fire Truck",
         Color.red, 8.95f, ProductSize.MEDIUM);

   private Product barbieClassic =
      new Product("b7654", "Barbie Classic",
         Color.yellow, 15.95f, ProductSize.SMALL);

   private Product frisbee =
      new Product("f4321", "Frisbee",
         Color.pink, 9.99f, ProductSize.LARGE);

   private Product baseball =
      new Product("b2343", "Baseball",
         Color.white, 8.95f, ProductSize.NOT_APPLICABLE);

   private Product toyConvertible =
      new Product("p1112", "Toy Porsche Convertible",
         Color.red, 230.00f, ProductSize.NOT_APPLICABLE);

   protected void setUp() {
      finder = new ProductFinder(createProductRepository());
   }

   private ProductRepository createProductRepository() {
      ProductRepository repository = new ProductRepository();
      repository.add(fireTruck);
      repository.add(barbieClassic);
      repository.add(frisbee);
      repository.add(baseball);
      repository.add(toyConvertible);
      return repository;
   }

The testFindByColor() method checks whether the ProductFinder.byColor(…) method correctly finds red toys, while testFindByPrice() checks whether ProductFinder.byPrice(…) correctly finds toys at a given price:

public class ProductFinderTests extends TestCase...
   public void testFindByColor() {
      List foundProducts = finder.byColor(Color.red);
      assertEquals("found 2 red products", 2, foundProducts.size());
      assertTrue("found fireTruck", foundProducts.contains(fireTruck));
      assertTrue(
         "found Toy Porsche Convertible",
         foundProducts.contains(toyConvertible));
   }

   public void testFindByPrice() {
      List foundProducts = finder.byPrice(8.95f);
      assertEquals("found products that cost $8.95", 2, foundProducts.size());
      for (Iterator i = foundProducts.iterator(); i.hasNext();) {
         Product p = (Product) i.next();
         assertTrue(p.getPrice() == 8.95f);
      }
   }

Here's the implementation code that satisfies these tests:

public class ProductFinder...
   private ProductRepository repository;

   public ProductFinder(ProductRepository repository) {
      this.repository = repository;
   }

   public List byColor(Color colorOfProductToFind) {
      List foundProducts = new ArrayList();
      Iterator products = repository.iterator();
      while (products.hasNext()) {
         Product product = (Product) products.next();
         if (product.getColor().equals(colorOfProductToFind))
            foundProducts.add(product);
      }
      return foundProducts;
   }
   public List byPrice(float priceLimit) {
      List foundProducts = new ArrayList();
      Iterator products = repository.iterator();
      while (products.hasNext()) {
         Product product = (Product) products.next();
         if (product.getPrice() == priceLimit)
            foundProducts.add(product);
      }
      return foundProducts;
   }

There's plenty of duplicate code in these two methods. We'll be getting rid of that duplication during this refactoring. Meanwhile, let us explore some more tests and code that are involved in the Combinatorial Explosion problem. Below, one test is concerned with finding Product instances by color, size, and below a certain price, while the other test is concerned with finding Product instances by color and above a certain price:

public class ProductFinderTests extends TestCase...
   public void testFindByColorSizeAndBelowPrice() {
      List foundProducts =
         finder.byColorSizeAndBelowPrice(Color.red, ProductSize.SMALL, 10.00f);
      assertEquals(
         "found no small red products below $10.00",
         0,
         foundProducts.size());

      foundProducts =
         finder.byColorSizeAndBelowPrice(Color.red, ProductSize.MEDIUM, 10.00f);
      assertEquals(
         "found firetruck when looking for cheap medium red toys",
         fireTruck,
         foundProducts.get(0));
   }

   public void testFindBelowPriceAvoidingAColor() {
      List foundProducts =
         finder.belowPriceAvoidingAColor(9.00f, Color.white);
      assertEquals(
         "found 1 non-white product < $9.00",
         1,
         foundProducts.size());
      assertTrue("found fireTruck", foundProducts.contains(fireTruck));

      foundProducts = finder.belowPriceAvoidingAColor(9.00f, Color.red);
      assertEquals(
         "found 1 non-red product < $9.00",
         1,
         foundProducts.size());
      assertTrue("found baseball", foundProducts.contains(baseball));
   }

Here's how the implementation code looks for these tests:

Now,let's start refactoring.

1) The first step is to find an object selection method that relies on a criterion argument for its selection logic. The ProductFinder method byColor(Color colorOfProductToFind) meets this requirement:

public class ProductFinder...
public List byColor(Color colorOfProductToFind) {
List foundProducts = new ArrayList();
Iterator products = repository.iterator();
while (products.hasNext()) {
Product product = (Product) products.next();
if (product.getColor().equals(colorOfProductToFind))
foundProducts.add(product);
}
return foundProducts;
}

We created a concrete specification class for the criterion argument, Color colorOfProductToFind. We call this class ColorSpec. It needs to hold onto a Color field and provide a getter method for it:

public class ColorSpec {
  
private Color colorOfProductToFind;

  
public ColorSpec(Color colorOfProductToFind) {
     
this.colorOfProductToFind = colorOfProductToFind;
  
}

  
public Color getColorOfProductToFind() {
     
return colorOfProductToFind;
  
}

}

Now we can add a variable of type ColorSpec to the byColor(…) method and replace the reference to the parameter, colorOfProductToFind, with a reference to the specification's getter method:

public List byColor(Color colorOfProductToFind) {
  
ColorSpec spec = new ColorSpec(colorOfProductToFind);
   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product) products.next();
      if (product.getColor().equals(
spec.getColorOfProductToFind()))
         foundProducts.add(product);
   }
   return foundProducts;
}

2. Now We'll extract the conditional statement in the while loop to an isSatisfiedBy(…) method:

public List byColor(Color colorOfProductToFind) {
   ColorSpec spec = new ColorSpec(colorOfProductToFind);
   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product) products.next();
      if (
isSatisfiedBy(spec, product))
         foundProducts.add(product);
   }
   return foundProducts;
}


private boolean isSatisfiedBy(ColorSpec spec, Product product) {
  
return product.getColor().equals(spec.getColorOfProductToFind());

}

The isSatisfiedBy(…) method can now be moved to ColorSpec class.

public class ProductFinder...
   public List byColor(Color colorOfProductToFind) {
      ColorSpec spec = new ColorSpec(colorOfProductToFind);
      List foundProducts = new ArrayList();
      Iterator products = repository.iterator();
      while (products.hasNext()) {
         Product product = (Product) products.next();
         if (
spec.isSatisfiedBy(product))
            foundProducts.add(product);
      }
      return foundProducts;
   }

public class ColorSpec...
  
boolean isSatisfiedBy(Product product) {
     
return product.getColor().equals(getColorOfProductToFind());
  
}

Finally, we create a specification superclass.

public abstract class Spec {
  
public abstract boolean isSatisfiedBy(Product product);

}

we make ColorSpec extend this class:

public class ColorSpec
extends Spec...

3. Now we repeat steps 1 and 2 for similar object selection methods. This includes methods that work with criteria (i.e., multiple pieces of criterion). For example, the byColorAndBelowPrice(…) method accepts two arguments that act as criteria for selecting Product instances out of the repository:

public List byColorAndBelowPrice(Color color, float price) {
   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product)products.next();
      if (product.getPrice() < price && product.getColor() == color)
         foundProducts.add(product);
   }
   return foundProducts;
}

By implementing steps 1 and 2, we end up with the BelowPriceSpec class:

public class BelowPriceSpec extends Spec {
  
private float priceThreshold;

  
public BelowPriceSpec(float priceThreshold) {
     
this.priceThreshold = priceThreshold;
  
}
  
public boolean isSatisfiedBy(Product product) {
     
return product.getPrice() < getPriceThreshold();
  
}
  
public float getPriceThreshold() {
     
return priceThreshold;
  
}

}

Now we can create a new version of byColorAndBelowPrice(…) that works with the two concrete specifications:

public List byColorAndBelowPrice(Color color, float price) {
  
ColorSpec colorSpec = new ColorSpec(color);
  
BelowPriceSpec priceSpec = new BelowPriceSpec(price);
   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product)products.next();
      if (
colorSpec.isSatisfiedBy(product) &&
        
priceSpec.isSatisfiedBy(product))
         foundProducts.add(product);
   }
   return foundProducts;
}

4. The byColorAndBelowPrice(…) method uses criteria (color and price) in its object selection logic. We'd like to make this method, and others like it, work with a composite specification rather than with individual specifications. To do that, We'll implement a modified version of step 1 and an unmodified version of step 2. Here's how byColorAndBelowPrice(…) looks after step 1:

public List byColorAndBelowPrice(Color color, float price) {
   ColorSpec colorSpec = new ColorSpec(color);
   BelowPriceSpec priceSpec = new BelowPriceSpec(price);
  
AndSpec spec = new AndSpec(colorSpec, priceSpec);

   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product)products.next();
      if (
spec.getAugend().isSatisfiedBy(product) &&
        
spec.getAddend().isSatisfiedBy(product))
         foundProducts.add(product);
   }
   return foundProducts;
}

The AndSpec class looks like this:

public class AndSpec {
  
private ProductSpecification augend, addend;

  
public AndSpec(Spec augend, Spec addend) {
     
this.augend = augend;
     
this.addend = addend;
  
}
  
public Spec getAddend() {
     
return addend;
  
}
  
public Spec getAugend() {
     
return augend;
  
}

}

After implementing step 2, the code now looks like this:

public List byColorAndBelowPrice(Color color, float price) {
   ...
   AndSpec spec = new AndSpec(colorSpec, priceSpec);

   while (products.hasNext()) {
      Product product = (Product)products.next();
      if (
spec.isSatisfiedBy(product))
         foundProducts.add(product);
   }
   return foundProducts;
}

public class AndSpec
extends Spec...
  
public boolean isSatisfiedBy(Product product) {
     
return getAugend().isSatisfiedBy(product) &&
        
getAddend().isSatisfiedBy(product);
  
}

We now have a composite specification that handles an AND operation to join two concrete specifications. In another object selection method called belowPriceAvoidingAColor(…), I have more complicated conditional logic:

public class ProductFinder...
   public List belowPriceAvoidingAColor(float price, Color color) {
      List foundProducts = new ArrayList();
      Iterator products = repository.iterator();
      while (products.hasNext()) {
         Product product = (Product) products.next();
         if (product.getPrice() < price && product.getColor() != color)
            foundProducts.add(product);
      }
      return foundProducts;
   }

This code requires two composite specifications (AndProductSpecification and NotProductSpecification) and two concrete specifications. The conditional logic in the method can be portrayed as shown in the diagram on the following page.

My first task is to produce a NotSpec:

public class NotSpec extends Spec {
  
private Spec specToNegate;

  
public NotSpec(Spec specToNegate) {
     
this.specToNegate = specToNegate;
  
}
  
public boolean isSatisfiedBy(Product product) {
     
return !specToNegate.isSatisfiedBy(product);
  
}

}

Then I modify the conditional logic to use AndSpec and NotSpec:

public List belowPriceAvoidingAColor(float price, Color color) {
  
AndSpec spec =
     
new AndSpec(
        
new BelowPriceSpec(price),
        
new NotSpec(
           
new ColorSpec(color)
        
)
     
);

   List foundProducts = new ArrayList();
   Iterator products = repository.iterator();
   while (products.hasNext()) {
      Product product = (Product) products.next();
      if (
spec.isSatisfiedBy(product))
         foundProducts.add(product);
   }
   return foundProducts;
}

That takes care of the belowPriceAvoidingAColor(…) method. I continue replacing logic in the object selection methods until all of them use either one concrete specification or one composite specification.

5. The bodies of all object selection methods are now identical, except for the specification creation logic:

Spec spec = ...create some spec
List foundProducts = new ArrayList();
Iterator products = repository.iterator();
while (products.hasNext()) {
   Product product = (Product) products.next();
   if (
spec.isSatisfiedBy(product))
      foundProducts.add(product);
}
return foundProducts;

Hence,we successfully applied Refactoring to our code using "Interpreter" Pattern.