strategy pattern and variables with interfaces

I have a this java application i am working on to get more experience with design patterns and OODesign. The application allows the user to select "equations" from a list. And then the user will be prompted with parameters for the selected equation and will be given a button to press to solve the equations.

I am implementing the equations as a strategy pattern. I am trying to figure out how to get the names of the equations into the list box. I was wondering if there was a way for the Equation classes that implement the EquationInterface to have a variable called equationName. That would allow the programmer to assign the specific equation a name when they are coding up the class for that specific equation. Code is listed below.

Example: When the programmer is designing a new equation to add to the program, they are required to include a name for the strategy created.

If yo开发者_StackOverflowu have any questions, please let me know. I am having a hard time explaining what i am trying to accomplish. And if you have any suggestions on a better design patter to use or way of accomplishing this goal, please let me know.

public class Equation {
    public enum equationList {
        DISTANCETRAVELLEDFALLINGOVERTIME,
        TIMEFOROBJECTFALLDISTANCE
    }

    private EquationInterface solveInterface;

    public Equation(EquationInterface solveInterface) {
        this.solveInterface = solveInterface;
    }

    public void solve() {
        solveInterface.performSolve();
    }

    public JPanel getParameterPanel() {
        return solveInterface.createParameterPanel();
    }
}

---

public interface EquationInterface {

    public JPanel createParameterPanel();

    public void performSolve();
}

---

public class DistanceTravelledFallingOverTime implements EquationInterface {

    @Override
    public void performSolve() {
        // TODO Auto-generated method stub
        System.out.println("DistanceTravelledFallingOverTime");
    }

    @Override
    public JPanel createParameterPanel() {
        // TODO Auto-generated method stub
        return null;
    }

}

---

public interface EquationInterface {

    public JPanel createParameterPanel();

    public void performSolve();

    public void setEquationName(String equationName);
    public String getEquationName();
}

I would use getter type method instead of a variable.

One sample implementation

public class  SampleEquation implements EquationInterface {

    public JPanel createParameterPanel(){return null;}

    public void performSolve(){
    //solving an equation
    }

    private String equationName = "MyDefaultEquationName";// or = null

    public void setEquationName(String equationName){
      this.equationName = equationName;
    }

    public String getEquationName(){
      return this.equationName;
    }
}

---

I would go with adding a getEquationName() into the EquationInterface interface:

public interface EquationInterface {

    public JPanel createParameterPanel();

    public void performSolve();

    public String getEquationName();
}

Sample implementation would look like:

public class DistanceTravelledFallingOverTime implements EquationInterface {

    @Override
    public void performSolve() {
        // TODO Auto-generated method stub
        System.out.println("DistanceTravelledFallingOverTime");
    }

    @Override
    public JPanel createParameterPanel() {
        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public String getEquationName(){
      return "Distance Travelled Falling Over Time";
    }

}

Furthermore, I would suggest another improvement in your design. Take a look at the EquationInterface interface; it looks a bit thick to me. It contains the getEquationName() and performSolve() methods which make a lot of sense. They are both concerned with the actual functionality of an equation. However, having a UI related method such as createParameterPanel() looks very odd to me. The interface now has a dependency on JPanel class and it is somehow tied to the UI. I would really break the interface into two; EquationInterface would contain the naming and the solution, while another interface would serve as to create the UI elements.

That also kind of answers your worries about the strategy pattern; the EquationInterface now would only be linked to the actual logic of an equation, including the name. In other words, it should feel more natural to add the naming logic into the interface. More details on this topic of interface segregation can be found here.