¿Cuál es la mejor manera de llamar a un método que solo está disponible para una clase que implementa una interfaz pero no la otra?

Básicamente necesito ejecutar diferentes acciones dada una cierta condición. El código existente se escribe de esta manera.

Interfaz base

// DoSomething.java
interface DoSomething {

   void letDoIt(String info);
}

Implementación de la primera clase obrera.

class DoItThisWay implements DoSomething {
  ...
}

Implementación de la segunda clase obrera.

class DoItThatWay implements DoSomething {
   ...
}

La clase principal

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          worker = new DoItThisWay();
        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

Este código funciona bien y es fácil de entender.

Ahora, debido a un nuevo requisito, necesito pasar una nueva información que solo tiene sentido DoItThisWay.

Mi pregunta es: ¿es bueno el siguiente estilo de codificación para manejar este requisito?

Use una nueva variable de clase y método

// Use new class variable and method

class DoItThisWay implements DoSomething {
  private int quality;
  DoSomething() {
    quality = 0;
  }

  public void setQuality(int quality) {
    this.quality = quality;
  };

 public void letDoIt(String info) {
   if (quality > 50) { // make use of the new information
     ...
   } else {
     ...
   }
 } ;

}

Si lo hago de esta manera, necesito hacer el cambio correspondiente a la persona que llama:

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          int quality = obtainQualityInfo();
          DoItThisWay tmp = new DoItThisWay();
          tmp.setQuality(quality)
          worker = tmp;

        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

¿Es un buen estilo de codificación? ¿O puedo simplemente lanzarlo?

   class Main {
     public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
          int quality = obtainQualityInfo();
          worker = new DoItThisWay();
          ((DoItThisWay) worker).setQuality(quality)
        } else {
          worker = new DoItThatWay();
        }
        worker.letDoIt(info)
     }

Supongo que qualitydebe establecerse junto con cada letDoIt()llamada en a DoItThisWay().

El problema que veo surgir aquí es el siguiente: está introduciendo el acoplamiento temporal (es decir, ¿qué sucede si olvida llamar setQuality()antes de llamar letDoIt()a un DoItThisWay?). Y las implementaciones para DoItThisWayy DoItThatWayson divergentes (uno debe haber setQuality()llamado, el otro no).

Si bien esto puede no causar problemas en este momento, puede volver a perseguirte eventualmente. Puede valer la pena echarle otro vistazo letDoIt()y considerar si la información de calidad podría ser parte de la información que infousted pasa; Pero esto depende de los detalles.

¿Es un buen estilo de codificación?

Desde mi punto de vista, ninguna de sus versiones es. Primero tener que llamar setQualityantes de que letDoItse pueda llamar es un acoplamiento temporal . Estás atrapado viendo DoItThisWaycomo un derivado de DoSomething, pero no lo es (al menos no funcionalmente), es más bien algo así como un

interface DoSomethingWithQuality {
   void letDoIt(String info, int quality);
}

Esto haría Mainmás bien algo como

class Main {
    // omitting the creation
    private DoSomething doSomething;
    private DoSomethingWithQuality doSomethingWithQuality;

    public doingIt(String info) {
        DoSomething worker;
        if (info == 'this') {
            int quality = obtainQualityInfo();
            doSomethingWithQuality.letDoIt(info, quality);
        } else {
            doSomething.letDoIt(info);
        }
    }
}

Por otro lado, podría pasar los parámetros a las clases directamente (suponiendo que esto sea posible) y delegar la decisión de cuál usar en una fábrica (esto haría que las instancias sean intercambiables nuevamente y ambas puedan derivarse DoSomething). Esto haría que se Mainvea así

class Main {
    private DoSomethingFactory doSomethingFactory;

     public doingIt(String info) {
         int quality = obtainQualityInfo();
         DoSomething doSomethingWorker = doSomethingFactory.Create(info, quality);
         doSomethingWorker.letDoIt();
     }
}

Soy consciente de que escribiste eso

porque por razones de rendimiento, la construcción de DoItThisWay y DoItThatWay se realiza una vez en el constructor de Main

Pero podría almacenar en caché las piezas que son costosas de crear en la fábrica y pasarlas también al constructor.

Supongamos que qualityno se puede pasar al constructor, y setQualityse requiere la llamada a .

Actualmente, un fragmento de código como

    int quality = obtainQualityInfo();
    worker = new DoItThisWay();
    ((DoItThisWay) worker).setQuality(quality);

es demasiado pequeño para invertir demasiado en ello. En mi humilde opinión, se ve un poco feo, pero no es realmente difícil de entender.

Los problemas surgen cuando tal fragmento de código crece y debido a la refactorización terminas con algo como

    int quality = obtainQualityInfo();
    worker = CreateAWorkerForThisInfo();
    ((DoItThisWay) worker).setQuality(quality);

Ahora, no ves de inmediato si ese código sigue siendo correcto, y el compilador no te lo dirá. Por lo tanto, introducir una variable temporal del tipo correcto y evitar el reparto es un poco más seguro, sin ningún esfuerzo adicional real.

Sin embargo, en realidad le daría tmpun mejor nombre:

      int quality = obtainQualityInfo();
      DoItThisWay workerThisWay = new DoItThisWay();
      workerThisWay.setQuality(quality)
      worker = workerThisWay;

Tales nombres ayudan a hacer que el código incorrecto parezca incorrecto.

Una interfaz común donde la inicialización varía según los datos de tiempo de ejecución generalmente se presta al patrón de fábrica.

DoThingsFactory factory = new DoThingsFactory(thingThatProvidesQuality);
DoSomething doSomething = factory.getDoer(info);

doSomething.letDoIt();

Entonces DoThingsFactory puede preocuparse por obtener y establecer la información de calidad dentro del getDoer(info)método antes de devolver el objeto concreto DoThingsWithQuality emitido a la interfaz DoSomething.