É uma má prática criar uma subclasse no nome apenas para facilitar a leitura?

Eu tenho três sensores em um único pacote que precisam ser calibrados, os quais chamarei de sens1, sens2 e sens3. A calibração para sens1 e sens2 é idêntica, mas a calibração para sens3 requer um parâmetro extra. Minha pergunta é: "Qual é a melhor maneira de lidar com três objetos quase idênticos, mantendo a legibilidade?"

Meu primeiro pensamento, é claro, foi usar polimorfismo. Eu configuraria um objeto Sensor genérico com um método .calibrate (Parameters params) em que a classe Parameters me permite variar o número de parâmetros com base na calibração que estou fazendo. No entanto, isso leva ao seguinte:

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

Para que as futuras pessoas precisem saber que um sensor é fundamentalmente diferente dos outros dois, mas muito parecido, parece-me que a melhor coisa a fazer é subclassificar Sens1 e Sens2 apenas no nome. Em outras palavras, faça duas subcategorias que não modifiquem ou estendam nenhum comportamento para ter mais nomes de classe lógicos. Lembre-se de que todos esses três sensores estão no mesmo pacote, portanto, esses dados frequentemente se combinam. Isso altera o código acima para:

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

Onde

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

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

Estou louco por pensar que é uma boa ideia? Existe um padrão mais limpo que estou completamente ausente aqui?

Conforme escrito (que pode ser simplificado demais), parece que os Sensores são todos iguais no comportamento geral, mas os Parâmetros para calibração são diferentes.

Se essa fosse a única diferença, e você estiver usando uma linguagem com genéricos, como Java (usado abaixo), poderá gerar a classe pelos Parâmetros, algo como:

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

   abstract public void calibrated(CalibrationParameters parameters);
}

então um monte de

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

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

}

Advertência: digitada sem um IDE, para que possa haver erros de digitação ou erros ...

ps Concordo com Robert que nomes melhores seriam, er, melhores. Portanto, uma implementação concreta melhor seria:

public class Thermometer extends Sensor<ThermometerCalibration> {

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

}

Não se os melhores nomes descritivos para esses sensores forem Sensor1, Sensor2e Sensor3. Os números não indicam nenhuma característica distintiva entre os sensores.

Se as diferentes classes denotarem diferentes tipos de sensores, classes diferentes podem ser garantidas. É por isso que às vezes nos referimos às classes como tipos, embora a própria palavra "tipo" tenha um significado mais amplo.

PressureSensor extends Sensor
TemperatureSensor extends Sensor

Não tenho certeza se a calibração deve ser de responsabilidade do sensor ... eu consideraria criar 2 novas classes. Algo como SensorCalibratorBase, SensorCalibratorAdavanced. Em seguida, eu criaria uma instância específica do calibrador com base no estado do aplicativo e alimentaria a instância do sensor com a função Calibrar. Cada calibrador obteria os parâmetros necessários como argumentos do construtor.