jMetal: About the algorithm-problem relationship

I’m opening this issue to start the discussion about the algorithm-problem relationship.

My point of view is the following. An Algorithm in jMetal is a metaheuristic, so it is intended to solve a given problem, so I included the relationship “Algorithm solves Problem” in the class diagram.

On the other hand, the interface Algorithm does not make any reference to problems:

public interface Algorithm<R> extends Runnable, Serializable {
  public void run() ;
  public R getResult() ;
}

However, if we deep into the class hierarchy, all the Builder classes to configure and instantiate algorithms have one mandatory argument: the problem (I discussed about this with Matthieu in another issue), so the relationship Algorithm-Problem is in the code.

I agree that my view is very biased, because the concepts are clear to me.

We have several ways to proceed:

• Do nothing
• Consider renaming Algorithm as `Metaheuristic´, as in the former versions of jMetal. This vay, the relationship is implicit given the definition of what a metaheuristic is.
• Change the Algorithm interface. For example, a void setProblemToSolve() could be added, or the run() method could be changed to solve(Problem). Here, I like the run() method because it allows to run the algorithm in a thread, as Matthie suggested.

This discussion also applies to the relationship “Algorithm uses Operators”.

I’m open to suggestions about the most convenient way to proceed.