Category: Design Patterns

The beauty of the Façade pattern

February 2nd, 2011 · · Clean code, Design Patterns No comments - Tags: , , , ,

The façade pattern is one of my most used patterns. It works as the glue both within an application and as a boundary to dependencies.

It mainly comes in handy when solving the following problems:

  • Testability
  • Fluid design and readable APIs
  • Protection against external forces and changes

Testability
Ever so often test driving development becomes extremely expensive because the interfaces the code depends on is impossible to test against. This may just as well be internal legacy libraries as external libraries. To remedy the problem I use a façade interface that provides the operations I need. I then mock the expected behaviour of the operations when writing code required. With some careful planing the binding of the library implementation to my façade can then be done without to much hassle.

Fluid design and readable APIs
Each component within an application strives to resolve it’s own domain. This often results in the boundaries becoming a bit awkward. To help creating fluidity in design and APIs it is therefore often useful to create façades matching each domains language and a thin layer of bindings that glues the libraries together.

Protection against external forces and changes
When using external libraries, apart from the above issues with testability and fluidity, façades also help reduce the cost of upgrading the dependencies. Whenever an external library changes the only code in the application that will need to change is the binding to the façade.

The overhead for getting the above benefits is actually remarkably low. It is usually enough to create an interface that delegates it’s operations to the library it is a façade for. The binding can the be done using dependency injection or factories.

Even when it’s more difficult it’s usually only a matter of composition. I have some times had to compose the the logic of the integration on a couple of abstraction levels but then it has still been well worth it since it has simplified the usage of the API considerably.

It is a shame that I don’t get to see this pattern used more often. It would have reduced cost and complexity on many occasions.

How to create a factory for strategies without using if’s

January 24th, 2011 · · Design Patterns No comments - Tags: , , , ,

A recent discussion thread on the Design Patterns LinkedIn group got me thinking that a blog on how to create a factory for strategies in Java would be useful. The method below removes the need for if or switch statements.

I will start with the code and then go on to look at the details.

The Strategy interface:

package com.tomasmalmsten.examples.strategy;

public interface Strategy {
    void execute();
}

The Factory class:

package com.tomasmalmsten.examples.strategy;

import java.util.HashMap;
import java.util.Map;

public class StrategyFactory {
    public static final String DEFAULT_STRATEGY_KEY = "default";
    public static final String SPECIFIC_STRATEGY_KEY = "specific";

    private static StrategyFactory instance = new StrategyFactory();

    private Map<String, Strategy> strategies = new HashMap<String, Strategy>(2);

    private StrategyFactory() {
        strategies.put(DEFAULT_STRATEGY_KEY, new DefaultStrategy());
        strategies.put(SPECIFIC_STRATEGY_KEY, new SpecificStrategy());
    }

    public Strategy findStrategyForKey(String key) {
        return strategies.get(key);
    }

    public static StrategyFactory getInstance() {
        return instance;
    }
}

A strategy implementation:

package com.tomasmalmsten.examples.strategy;

public class DefaultStrategy implements Strategy {

    DefaultStrategy() {}

    public void execute() {
        System.out.println("Default Strategy!");
    }
}

Another strategy implementation:

package com.tomasmalmsten.examples.strategy;

public class SpecificStrategy implements Strategy {

    SpecificStrategy() {}

    public void execute() {
        System.out.println("Specific Strategy!");
    }
}

The example code is fairly simple. The complexity lies in how to create the factory and what responsibility it should have compared to the strategies. According to the single responsibility principle a class should only have one responsibility. Therefore the strategy should not do anything else then execute. The factories responsibility is to provide strategies to the client. Therefore it’s singleton instance does just that.

The client only need to know the key of the strategy it needs. This can be derived by class name, key word or something else and is stored as the key in the map that finds the correct strategy instance. To make the client logic simpler I have used Enum types to maintain keys in the past. The enum will then be able to create a valid key based on whatever is logical for the specific client.

Also note the access modifiers used for constructors. All creation logic is isolated to the package. This makes it easy to maintain since we know that nothing outside of the package can create new instances and instead has to use the factory to get an instance of the strategy.

The same recipe works well for creating other similar factories as well, for example Command factories.