Dienstag, 27. August 2013

Policy Driven Implementation

Dominant design patterns for domain models are the strategy and the composite pattern. To build rich domain models with both patterns is an honest achievement. My focus in the following explanation  is on the strategy pattern which is the base for the implementation of policies. Policies are true friends in case of designing an application programming interface. Policies guarantee the possibility to alter algorithms in the background without the need to touch a previous released interface. It might be true, that this is only one part of the story. To ensure extensibility you need another design pattern which uses overriding in a subclass. As you already assumed, it is the template method or factory method pattern.

Duke proudly presents the definition for the strategy pattern:

Define a family of algorithms, encapsulate each one and make them interchangeable.
The strategy pattern lets the algorithm vary independently from clients that use it.
[Gang of Four]


The power of design patterns is hidden in their combinations. But be aware: A design pattern should be applied only when it’s needed! Well, don’t worry now. Look first to solve your business problem and then look for a combination of patterns to ensure that your software is reusable and extensible.

The strategy and template method patterns are a strong combination to write software which meets the criteria of the Open Closed Principle (OCP). The strategy makes the algorithms changeable and the template method pattern ensures the extensibility without touching an existing implementation. For sure it’s difficult to see such combinations in a deep object oriented class hierarchy, but on the other hand a few principles will help you to build robust object oriented software. Consider first the usage of the template or factory method pattern and then decide how you can vary your algorithms in your system context which will lead to a policy driven implementation.

The following example is the implementation of a billing class with two variants. The first variant is the implementation of a 19% tax billing class and the second one is a 7% tax billing class. The implementation uses the template method pattern to determine the tax rate and the strategy pattern to implement the tax rate read strategy.

Billing base class:

package org.ccd.policy;

import java.math.BigDecimal;

abstract class Billing {

    private final BigDecimal price;   
   
    protected Billing(final BigDecimal price) {
       
        this.price = price;
    }
   
    /**
     * Calculate the price including
     * the tax rate.
     *
     * @return price * tax rate
     */
    public BigDecimal calculate() {       
        return price.multiply(tax());
    }

    /**
     * The tax rate method.
     *
     * @return tax rate
     */
    protected abstract BigDecimal tax();
   
    /**
     * The TaxPolicy interface.
     */
    protected interface TaxPolicy {       
        public BigDecimal rate();
    }
}

Billing min tax rate subclass:

package org.ccd.policy;

import java.math.BigDecimal;

public class BillingMinTaxRate extends Billing {
  
    public BillingMinTaxRate(final BigDecimal price) {      
        super(price);
    }
  
    @Override
    protected BigDecimal tax() {
      
        return new TaxPolicy() {

            @Override
            public BigDecimal rate() {
              
                // read tax rate from database,
                // it's a fake right here!
                final BigDecimal taxRate = new BigDecimal("1.07");
              
                return taxRate;
            }
          
        }.rate();
    }
}

Billing max tax rate subclass:

package org.ccd.policy;

import java.math.BigDecimal;

public class BillingMaxTaxRate extends Billing {
   
    public BillingMaxTaxRate(final BigDecimal price) {       
        super(price);
    }
   
    @Override
    protected BigDecimal tax() {
       
        return new TaxPolicy() {

            @Override
            public BigDecimal rate() {
               
                // read tax rate from database,
                // it's a fake right here!
                final BigDecimal taxRate = new BigDecimal("1.19");
               
                return taxRate;
            }
           
        }.rate();
    }
}

Billing test class:

package org.ccd.policy;

import static org.junit.Assert.*;
import org.junit.Test;
import java.math.BigDecimal;

public class BillingTest {

    @Test
    public void testBillingMinTaxrate() {
       
       final Billing billingMinTaxRate =
            new BillingMinTaxRate(new BigDecimal("10.00"));
       
        assertEquals(new BigDecimal("10.70").doubleValue(),
                billingMinTaxRate.calculate().doubleValue(),
                new BigDecimal("0.00").doubleValue());       
    }
   
    @Test
    public void testBillingMaxTaxrate() {
       
        final Billing billingMaxTaxRate =
             new BillingMaxTaxRate(new BigDecimal("10.00"));
               
        assertEquals(new BigDecimal("11.90").doubleValue(),
                     billingMaxTaxRate.calculate().doubleValue(),
                     new BigDecimal("0.00").doubleValue());       
    }
}



Der Rechtshinweis des Java Blog für Clean Code Developer ist bei der Verwendung und Weiterentwicklung des Quellcodes des Blogeintrages zu beachten.

Samstag, 24. August 2013

Thinking about caching

I have heard it multiple times: Caching is evil! The risks and benefits of caching are obvious. The main risks using a caching strategy are to work with stale data and to waste memory. On the other hand the benefits are reducing database access and increasing performance by reading pre calculated data. The Java EE entity manager (JPA) uses a first level cache and optional a second level cache. The first level cache is related to the persistence context which means the cache is valid between a single transaction. After the transaction commits or possibly after a rollback the first level cache is gone.


The second level cache (L2-Cache) has a longer lifetime. The second level cache is independent of a particular entity manager instance and the related transactions. Using a second level cache reduces database access to gain better performance. The second level cache should be configured that the count of maintained entities are limited and that the cache is refreshed automatically after an expired timeframe. To reduce the problem of stale data put mainly entities with static data in the second level cache. Static data are system data which could be application profile data, labels of an I18n strategy or fixed GUI related data which alter seldom.

The rule of thumb is:

Caching is valuable without risk for static data which are not refreshed during program execution. Caching can be evil for frequent altered data even in a transactional context.

Caching to reduce database access is one part of the story, but caching could also lead to better performance within the application itself. Java has several collection classes which supports safer caching to avoid stale data. A good example is the WeakHashMap.  An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use.

Since Java 5 the LinkedHashMap can be used as a LRU Cache (last recently used cache). By overriding the “removeEldestEntry” method to implement a policy for removing stale mappings automatically when new mappings are added. There are even more sophisticated caching solutions (e.g.: Ehcache) available which handle evict and refreshing better as the simple Java API implementations.

The conclusion is:  Caching could be evil when wrongly considered and valuable when considered with care. Therefore use caching with care!