Clase de contexto en el patrón de estrategia

Estoy tratando de entender el patrón de estrategia y me pregunto: ¿es imprescindible la clase de contexto o puedo dejarla sin comprometer el propósito del patrón?

Tenía la impresión de que necesitaba algún tipo de cambio para leer diferentes tipos de archivos, pero no quería simplemente hackear algo y luego tratar con la refactorización (aunque, por supuesto, siempre sucede que el código se puede refactorizar, pero la idea era: intentar ser lo más inteligente posible en el diseño de antemano ...):

Imagen tomada de wikimedia

¿Puede el cliente delegar directamente en la interfaz de la Estrategia o hay algo que acabo de perder de entender sobre la clase de contexto?

interface Reader {
    // read information from file and fill data list field of Client
    readFile();
}
class ExcelReader implements Reader{ /* */ }
class PdfReader implements Reader{ /* */}

class Client{
    // strategic choice
    Reader r;

    // data list field
    List<Data> data;

    // Client Constructor
    public Client(){
        if(<file ends in .xls>)
            r = new ExcelReader();
        else
            r = new PdfReader();
        r.readFile();
    }
}

Entonces, arriba se muestra la clase de contexto que falta. ¿Se adhiere el código al patrón de estrategia?

En su ejemplo, la llamada de código readFilees parte del constructor del Cliente. Ese método es el "contexto" que está buscando . El patrón de estrategia no necesita una "clase de contexto" literalmente, y en la primera versión de su código, el objeto de estrategia (el "Lector" en su caso) puede residir solo en una variable local. Especialmente cuando solo hay que llamar un "método estratégico" ("readFile").

Sin embargo, si su base de código crece de una versión a la siguiente, no es improbable que se recurra a más y más métodos "estratégicos", y la decisión de qué estrategia aplicar y la ejecución de los "métodos estratégicos" sucederán en diferentes momentos y en diferentes lugares en tu código. Entonces comienzas a refactorizarlos para mantener la lógica en un solo lugar. Esto conducirá directamente a una implementación similar al diagrama en su pregunta.

Ciertamente. Los patrones son solo pautas. Aún tendrá que adaptarlos y aplicarlos correctamente para el problema en cuestión. Personalmente, rara vez permito que la estrategia se establezca en tiempo de ejecución; más a menudo se especifica en la construcción o se hace girar en una fábrica.

Aunque también se podría argumentar que setStrategyes privado y mi inyección solo usa el patrón como se muestra.