1

I have two algorithms that share a lot of commonalities. One performs an iterative procedure, the other does just the first iteration. The results are, of course, different (one class provides results that the other can't), as well as the setup (the iterative process requires tolerances and max number of iterations, which are irrelevant in the non-iterative one).

Should I have a unique class with internal ifs (like if (iterative) do this else do that) or should I implement two different classes (and potentially put common code in an accessible place so that it can be shared ?) What do you think ?

0

3 Answers 3

3

It sounds like the Template Method Pattern:

A template method defines the program skeleton of an algorithm. One or more of the algorithm steps can be overridden by subclasses to allow differing behaviors while ensuring that the overarching algorithm is still followed.

For example:

abstract class Base {
    void stepOne(Object item) {
        // Do some stuff on item...
    }

    void stepTwo(Object item) {
        // Do some stuff on item...
    }

    void stepThree(Object item) {
        // Do some stuff on item...
    }

    void allSteps(Collection<Object> data) {
        for (Object x : data) {
            stepOne(x);
            stepTwo(x);
            stepThree(x);
        }
    }
}

class SpecificOne extends Base {
    @Override
    void stepTwo(Object item) {
        // Do something different on item
    }
}

class SpecificTwo extends Base {
    @Override
    void allSteps(Collection<Object> data) {
        for (Object x : data) {
            // The order is altered
            stepThree(x);
            stepTwo(x);
            stepOne(x);
        }
    }
}

Then you would use the different algorithms like this:

public class TMTest {
    public static void main(String[] args) {
        Collection<Object> items = ...;

        Base one = new SpecificOne();
        Base two = new SpecificTwo();

        one.allSteps(items);
        two.allSteps(items);
    }
}
2

Sounds like the procedure itself needs to be extracted and then have two different methods, one which runs the iterations and calls that procedure inside, and the other which just calls it once.

Response to comment:

Remember Don't repeat yourself. One of the most important parts of architecture is figuring out how to organize your code in ways that methods that still have similar parts have those similar parts separated so they can be shared. If they seem to be running the same algorithm but with different parameters, that's a perfect opportunity for a method (or, if there are multiple outputs, maybe a class).

3
  • this is already sort of done, but the point is at a higher level, namely: when two algorithms become sufficiently different to be granted a life on their own ? Jan 21, 2011 at 16:31
  • it's difficult to say if it's the same algo or not. The fact that you don't apply the iterative process implies that you cannot compute some data. In a sense, they are the same, because the steps are very similar, but the effect is different Jan 21, 2011 at 16:46
  • 1
    @Stefano, the way you describe it it sounds that your algorithms are sharing most of their functionality, only one case breaks out of the loop immediately. Sounds like a parameter is what you want. If that makes you feel uneasy set up a default argument and and introduce a second function that just sets the argument for the non-iterative algorithm. Jan 21, 2011 at 16:47
1

Take a look from user's perspective. When a user of one of the algorithms will need the other? When a user solves a typical problem for which these algorithms fit well, does it make sense for him to switch from one-step to iterative (or back) depending on some circumstances? That is, if you were to just use these algorithms, would the iterative parameter make sense in your daily work?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.