Java Strategy Pattern - can I delegate the creation of strategies in the Context class?

I am currently learning design patterns on my own. When I examined the strategy pattern, I found something that looks strange to me. I searched for discussions on this schema, but no one answered my question ... how can I implement the strategy pattern to keep it clean, to support encapsulation and make it easier to add a new strategy. To explain my problem here - the "canonical" strategy pattern:

public interface Strategy {
    public void run();
}

public class stratConcrt1 implements Strategy {/*run() implementation*/}
public class stratConcrt2 implements Strategy {/*run() implementation*/}

public class Context {
    private Strategy strategy;

    public Context(Strategy strat) {
        this.strategy = strat;
    }

    public void runStrategy() {
        this.strategy.run()
    }
}


public class Client {
    public void main(Strings[] args) {
        Context cx;

        cx = new Context(new stratConcrt1())
        cx.runStrategy();

        cx = new Context(new stratConcrt2())
        cx.runStrategy();
    }
}

      

        
        
        
      

    

I understand what's going on, but it seems strange to me that the client knows something about the different strategies that might be applied. It would be easier for me to allow the Context to create different strategies rather than the Client, since the Context deals with strategies which it should (at least in my opinion) be the only one who can create the strategy.

I have implemented a small example using JavaFx with some differences from the code above:

I have a class field that creates a list of coordinates, this class has a method to sort the list. The coordinate list sorting method is a method for which there are several strategies.

public class Field {

    // a field contains rectangles described in a list through their coordinates
    private ObservableList<Coordinate> mpv_coordinateList = FXCollections
                    .observableArrayList();

    private Context mpv_sortContext;

    // Constructor
    public Field() {
        //the rectangles are randomly created
        Random rd = new Random();
        for (int i = 0; i < 100; i++) {
            mpv_coordinateList.add(new Coordinate(rd.nextInt(490), rd.nextInt(490)));
        }

        //a context to dynamically modify the sort algorithm
        mpv_sortContext = new Context();
    }

    //returns the list with all rectangle
    public ObservableList<Coordinate> getField() {
        return this.mpv_coordinateList;
    }

    //sort elements (depending on different algorithms)
    public ObservableList<Coordinate> sortElements(String p_sortToApply) {
        return mpv_sortContext.launchSort(p_sortToApply,
                        this.mpv_coordinateList);
    }
}

      

        
        
        
      

    

As the model says, I created an interface and gave specific strategies inherited from that interface:

public interface SortStrategy {
    ObservableList<Coordinate> sort(ObservableList<Coordinate> p_listToSort);
}

public class EvenSort implements SortStrategy {
    @Override
    public ObservableList<Coordinate> sort(
                ObservableList<Coordinate> p_listToSort) {

        ObservableList<Coordinate> oddCoordList = FXCollections
                        .observableArrayList();

        for (Coordinate coord : p_listToSort) {
            if (coord.x % 2 == 0) {
                oddCoordList.add(coord);
            }
        }
        return oddCoordList;
    }
}

public class OddSort implements SortStrategy {
    @Override
    public ObservableList<Coordinate> sort(
                ObservableList<Coordinate> p_listToSort) {

        ObservableList<Coordinate> oddCoordList = FXCollections
                        .observableArrayList();

        for (Coordinate coord : p_listToSort) {
            if (coord.x % 2 == 1) {
                oddCoordList.add(coord);
            }
        }
        return oddCoordList;
    }
}

      

        
        
        
      

    

Concrete classes simply return a list containing all coordinates with an even or odd x coordinate.

and then I created a class context:

public class Context {
    //private SortStrategy mpv_sortStrategy; //never used

    private EvenSort mpv_evenSort = new EvenSort();
    private OddSort mpv_oddSort = new OddSort();
    private StandardSort mpv_standardSort = new StandardSort();

    private HashMap<String, SortStrategy> mpv_HashMapStrategies;


    public Context() {

        //creation of a dictionary with all possible strategies
        mpv_HashMapStrategies = new HashMap<String, SortStrategy>();
        mpv_HashMapStrategies.put("Even Sort", mpv_evenSort);
        mpv_HashMapStrategies.put("Odd Sort", mpv_oddSort);
        mpv_HashMapStrategies.put("Standard Sort", mpv_standardSort);
    }

    public ObservableList<Coordinate> launchSort(String p_sortToApply, ObservableList<Coordinate> p_listToSort){
        return mpv_HashMapStrategies.get(p_sortToApply).sort(p_listToSort);
    }
}

      

        
        
        
      

    

Through the gui, the user can choose the strategy he wants to use to sort the list. The user can click on the button to start sorting. The call is made through the main class (not shown) to inst_field.mpv_sortContext.sortElements(a_string)

with a string as parameters describing the strategy used. This line is then used in sortElements to select the instance of the strategy that the user wants to apply.

With my implementation, I have on the one hand the client and on the other hand all the code that deals with the strategies (Context, interface and concrete classes). If I want to add a new strategy, I just need to add the initialization of the new strategy in the Context class and the description of this new strategy in the gui so that the user is aware of it.

I know that the implementation I did is also not so good because the Context contains an instance for every possible strategy and because of this I don't need an interface reference, but I find it cleaner than field and client resolution knows about these classes.

Well ... Am I completely wrong? There is something I missed in the "canonical" strategy outline. Is the "canonical" way the only and only way to implement the strategy pattern? or is there a better way to implement this pattern in such a way that only the classes that need to know know about the strategy examples and a way that the new strategy can be added easily?