Home > Net >  Is there an alternative to Template Method pattern when using common logic?
Is there an alternative to Template Method pattern when using common logic?

Time:02-27

I have a problem. Most of the solutions in the project follow the Template Method design pattern. At the same time, along with the complexity of business logic, solutions are becoming more and more confusing.

For example, there is some Copier interface:

public interface Copier {

    void copy() {
        copyA();
        copyB();
    }
}

Some classes can implement this interface by this way:

public class MusicCopier implements Copier {

    @Override
    protected void copyA() {
        SomeUtils.copy(new File(...), new File(...)));
    }

    @Override
    protected void copyB() {
        // three arguments here
        SomeUtils.copy(new File(...), new File(...)), new File(...));
    }
}

public class DocumentsCopier implements Copier {

    @Override
    protected void copyA() {
        SomeUtils.copy(new File(...), new File(...)));
    }

    @Override
    protected void copyB() {
        // three arguments here
        SomeUtils.copy(new File(...), new File(...), new File(...)));
    }
}

Then somewhere these classes are used like this:

Copier musicCopier = new MusicCopier();
Copier documentsCopier = new DocumentsCopier();

musicCopier.copy();
documentsCopier.copy();

Etc. Great. Here comes the idea to replace the interface with an abstract class and bring the main logic there. Then the abstract class will look like this:

public abstract class Copier {

    protected void copy() {
        copyA();
        copyB();
    }
    
    protected void copyA() {
       SomeUtils.copy(getASource(), getADest()));
    }

    protected void copyB() {
       SomeUtils.copy(getBSource(), getBDest(), getBExcluded()));
    }
    
    // and these terrible methods overridden in superclasses:
    protected void getASource() {}
    protected void getBSource() {}
    protected void getADest() {}
    protected void getBDest() {}
    protected void getBExcluded() {}
    // protected void getOrSetWTF() {}
}

Accordingly, the subclasses will be as follows:

public class MusicCopier extends Copier {

    @Override
    protected void getASource() { /* pass some path here */}
    
    @Override
    protected void getBSource() {/* pass some path here */}
    
    @Override
    protected void getADest() {/* pass some path here */}
    
    @Override
    protected void getBDest() {/* pass some path here */}
    
    @Override
    protected void getBExcluded() {/* pass some path here */}
}

Etc. It turns out that we are "setting up logic", which is now all in an abstract class. And the more complicated it is, the more "get" (or "set"?) there are. All this creates confusion and such code is simply unpleasant to write - especially if the project is large and developers have to "configure superclasses".

In some subclasses, I need to do something else in copyA() or in copyB(). Then I have to override these methods entirely:

@Override
protected void copyA() {
    doSomethingHere();
    
    SomeUtils.copy(new File(...), new File(...)));
    
    doSomethingHereTo();
}

Or put these "doSomething" methods also in an abstract class and then override/implement it in subclasses.

Is there patterns or combinations of them that would help get rid of this ugly design?

CodePudding user response:

I would suggest instead of have a lot of methods to override, each returning one piece of info, to combine this methods so one object containing them all can be returned as result in one method.

It seems to me this info is related, so why not put them all together in an ‘RoutingInfo’-class or something.

You could refactor your class to have only a few ‘template-methods’, which return objects containing related information.

  • Related