Java Design Patterns – Is Template Design Pattern Bad Practice Due to Inheritance?

designdesign-patternsjavaobject-orientedobject-oriented-design

I have been using Template Design pattern in my code for implementing CRUD procedures for different resources.

There are some steps which are same for many resources and some which need some addition/overriding.

ResourceCommonProcedures as a base class and each Resource procedure inheriting the base class.

public class ResourceCommonProcedures { 

    public Response create(Request request){
        Response response = new Response();
        int resType = this.getResourceType(request);

        ResourceCommonProcedures rp = getResourceController(resType);
        response = rp.create(request);

        return response;
    }

private ResourceCommonProcedures getResourceController(int resourceType){
            //..

            switch(resourceTypeName){


            case Resource1:
                return new R1Procedures();

            case Resource2:
                return new R2Procedures();

            case Resource3:
                return new R3Procedures();
            ............... 

}
}

Class R1Procedures extends ResourceCommonProcedures{


public Response create(Request request) {

        Response response = new Response();
            Resource1 resource = (Resource1) request.getContent();

            ...........
            // Converts DB structure to JPA 
            R1Converter r1Converter = new R1Converter();
            Resource1JPA resourceJpa = r1Converter.toJPA(resource);
            dao.persist();

            return response;

}
}

Class R2Procedures extends ResourceCommonProcedures{


public Response create(Request request) {

        Response response = new Response();
            Resource1 resource = (Resource2) request.getContent();

            // SOME RESOURCE 2 SPECIFIC CODE
            ...........
            // Converts DB structure to JPA 
            R2Converter r2Converter = new R2Converter();
            Resource2JPA resourceJpa = r2Converter.toJPA(resource);
            dao.persist();

            return response;


}

As Joshua Bloch wrote in the third edition of Effective Java,

The Template Method pattern [..] is far less attractive. The modern alternative is to provide a static factory or constructor that accepts a function object to achieve the same effect.

I feel the code reuse in 10-15 resources procedures I am writing is significant.
Shall Template design pattern be avoided due to Inheritance ?

Best Answer

Inheritance is not bad per se. It depends on how you use it. Avoiding a technique just because someone says it is bad is not a good way to make decisions.

While I see where Josh Bloch is coming from, the alternative he proposes is not quite the same thing. The Template pattern aims to enforce a particular design; it takes advantage of the rigidity of base classes to achieve this end. The static factory or constructor, on the other hand, focuses more on flexibility and decoupling because it is compatible with Dependency Injection techniques.

In other words, they have two (somewhat) different purposes.

When deciding on whether or not to use a particular software development technique, evaluate it on its relative merits within the context of your particular project, not on the summary opinions of others. Let those opinions guide you, if you wish, but always be the final arbiter.

Further Reading
Template Method Pattern
Java Constructors vs Static Factory Methods
Function object

Related Solutions

Java – Implementing strategy pattern multiple variables

The intent of the strategy pattern according to the GoF is to "define a family of algorithms, encapsulate them and make them interchangeable. The strategy lets algorithms vay independently from client that use it"

In your code you apply this pattern, making a strategy of ContentHandler that can be declined in different concrete content handling, depending on the requests to pursue.

Problem with the switch approach:

However, in your implementation the serialization depends on the format you want to use. The way you pass a content type, using lots of switch blocks to produce the appropriate format, will make the code very difficult to maintain: each content handler implementation will have to provide for all kind of formats. Imagine that one day you'd like to add a new format (for example bson) : you'd need to review all the switch blocks of all your concrete implementation of ContentHandler. That's a huge work, and clearly does not very well enforce separation of concerns.

Alternative:

But looking at it more closely, you have here an opportunity to add a second level of strategies. Each of your switch block would correspond to a kind of primitive operation on the content to produce the format. It's another family of algorithms. You should hence make the format a strategy as well:

public interface SerialFormatter {
    String createStringNode(...);  
    String openSubbloc(...);  
    ... // you have to analyze your switch blocks to determine the primitives
};

And then regroup all format specific primitives according to this logic:

class JSONFormatter implements SerialFormatter { ... }; 
class XMLFormatter implements SerialFormatter { ... };

If one day you want to support a new format, just add a new class of this kind.

You then can simplify your serializer logic:

String serializeRequest(Content con, SerialFormatter fmt){
   // ....
   String s = fmt.openSubbloc ("ID") + 
       fmt.createStringNode ("Name", con.name() ) +
       ...
       fmt.closeSubbloc("ID"); 
   return s;  
 }

Conclusion

Design using combination of multiple strategies is sometimes called "policy based design" It is a very powerful approach: with n kind of requests and m format, you'd write m+n classes with single responsibility, instead of writing nm classes (see other answer to your question) or writing n classes and at least nm rather redundant cases.

Java Design Patterns – Combining Inheritance and Factory Patterns

I would go for an abstract generic class :

public class AbstractProcedure<T extends BusinessObject, TJPA extends JPAObject, TConverter extends Converter<T, TJPA >>{

public abstract TConverter<T, TJPA> getConverter();

public Response create(Request request) {
    Response response = new Response();
        T resource = (T) request.getContent();

        ...........
        // Converts DB structure to JPA 
        R1Converter r1Converter = getConverter();
        TJPA resourceJpa = r1Converter.toJPA(resource);
        dao.persist(resourceJpa);
        return response;
    }
 }

public class R1Converter implements Converter<R1, R1JPA>{
         @Override // come from the Converter interface
         public R1JPA toJpa(R1 object){}
}
public class R1Procedure extends AbstractProcedure<R1, R1JPA, R1Converter>{
      R1Converter converter = new R1Converter();
      public R1Converter getConverter(){
           return converter;
      }
}

Some point to consider :

You might want to rename your "Converter" to "Adapter"
Handling the database request in the same class than getting the data from the request is usually done is separated classes for separation of concerns. What if tomorrow a batch have to create entities ?
You can override create function to add some default value, right check and call super.create(). Though usage of super is not recommended, this is a sane usage of it IMHO.

Best Answer

Related Solutions

Java – Implementing strategy pattern multiple variables

Java Design Patterns – Combining Inheritance and Factory Patterns

Related Topic