¿Es una mala práctica hacer una subclase en nombre solo para facilitar la lectura?

Tengo tres sensores en un solo paquete que todos necesitan ser calibrados, lo que llamaré sens1, sens2 y sens3. La calibración para sens1 y sens2 son idénticas, pero la calibración para sens3 requiere un parámetro adicional. Mi pregunta es: "¿Cuál es la mejor manera de lidiar con tres objetos casi idénticos mientras se mantiene la legibilidad?"

Mi primer pensamiento, por supuesto, fue utilizar el polimorfismo. Instalaría un objeto Sensor genérico con un método .calibrate (Parámetros parámetros) donde la clase Parameters me permite variar el número de parámetros en función de la calibración que estoy haciendo. Sin embargo, esto lleva a lo siguiente:

Sensor sens1 = new Sensor();
Sensor sens2 = new Sensor();
Sensor3 sens3 = new Sensor3();

Para que las personas futuras necesiten saber que un sensor es fundamentalmente diferente de los otros dos, pero muy similar, me parece que lo mejor es subclasificar Sens1 y Sens2 solo de nombre. En otras palabras, cree dos subcuadros que no modifiquen ni amplíen ningún comportamiento para tener más nombres de clase lógica. Recuerde, los tres sensores están en el mismo paquete, por lo que estos datos a menudo van juntos. Esto cambia el código anterior a:

Sensor1 sens1 = new Sensor1();
Sensor2 sens2 = new Sensor2();
Sensor3 sens3 = new Sensor3();

dónde

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

Sensor3 extends Sensor {
    @Override
    calibrated(Parameters params) {
        \\ Code
    }
}

¿Estoy loco por pensar que esta es una buena idea? ¿Hay un patrón más limpio que me falta por completo aquí?

Tal como está escrito (que puede estar demasiado simplificado), parece que los sensores son todos iguales en el comportamiento general, pero los parámetros para la calibración son diferentes.

Si esta fuera la única diferencia, y está utilizando un lenguaje con genéricos, como Java (utilizado a continuación), podría generar la clase por los Parámetros, algo como:

abstract class Sensor<CalibrationParameters> {
   // constructor, getters, setters, etc...

   abstract public void calibrated(CalibrationParameters parameters);
}

entonces un montón de

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

   public void calibrated(CalibrationParametersForSensorN parameters) {
      ...
   }

}

Advertencia: escrito sin un IDE, por lo que puede haber errores tipográficos o errores ...

PD. Estoy de acuerdo con Robert en que mejores nombres serían, er, mejores. Entonces, una mejor implementación concreta sería:

public class Thermometer extends Sensor<ThermometerCalibration> {

    public void calibrated(ThermometerCalibration parameters) {
       ...
    }

}

No si los mejores nombres descriptivos para estos sensores son Sensor1, Sensor2y Sensor3. Los números no indican ninguna característica distintiva entre los sensores.

Si las diferentes clases denotan diferentes tipos de sensores, entonces se pueden justificar diferentes clases. Es por eso que a veces nos referimos a las clases como tipos, aunque la palabra "tipo" en sí misma tiene un significado más amplio.

PressureSensor extends Sensor
TemperatureSensor extends Sensor

No estoy seguro de si la calibración debería ser responsabilidad del sensor ... Consideraría crear 2 nuevas clases. Algo como SensorCalibratorBase, SensorCalibratorAdavanced. Luego, crearía una instancia específica del calibrador basada en el estado de la aplicación y alimentaría la instancia del sensor a su función Calibrar. Cada calibrador obtendría los parámetros necesarios como argumentos de constructor.