There are a number of design patterns which I have chosen not to implement a coding kata for. This is because I felt that I would either not use the pattern regularly in practice or they have alternative solutions that make the pattern redundant. However I think it is worth calling out these patterns and summarising how they work.

The decorator pattern

This pattern provides a way of extending a classes behaviour without using inheritance, it is defined as:

The decorator pattern extends the functionality of individual objects by wrapping them with one or more decorator classes. These decorators can modify existing members and add new methods and properties at run-time.

The main reason I won’t be using this pattern much in practice is that the class structure it generates is not very clear and also the behaviour of the classes can change depending on the order they are instantiated. So I think implementing this pattern could cause more problems than it solves, especially if the system may need to be maintained by different people at a later date.

The factory pattern

The factory method pattern allows for the creation of objects without specifying the type of object that is to be created in code. A factory class contains a method that allows determination of the created type at run-time.

Whilst the factory method has its uses it is basically just an implementation of sub classing, where parameters are defined as base classes to allow different derived classes to be passed at runtime. It is a straightforward pattern and the coding kata would be pretty short to implement it.

Also one of the main issues the factory pattern tries to solve is centralising object creation, however we generally use IoC containers which provide low maintenance dependency injection out of the box. So this removes the main need for the factory pattern.

The Singleton pattern

Ensure a class only has one instance and provide a global access point to it

This is a pattern which can be very useful in applications, however the implementation is so short that a coding kata would have little content. There are just a couple of pitfalls to watch out for when implementing this pattern:

• Ensure the implementation is thread safe In Java the synchronized keyword can be used on the method which returns the singleton to ensure only a single thread ever has access to the class at once. However that can lead to the second pitfall
• Consider whether you implementation offers the best performance Using synchronization is expensive (ie. It takes the computer a relatively long time to process)

This implementation avoids both of these pitfalls by creating the uniqueInstance when the class is first loaded:

public class Singleton {
  private static Singleton uniqueInstance = new Singleton();

  private Singleton() {}

  public static Singleton getInstance()  {
    return uniqueInstance;
  }
}

Finally, as with the factory pattern, if you are using an IoC container then they generally provide a way to configure a class as a singleton so there is rarely a need to implement this pattern manually yourself.

There may be more…

Stay tuned for more patterns to be added to this post!