Is it bad practice to make a subclass in name only for readability?

Question

I have three sensors in a single package that all need to be calibrated which I will call sens1, sens2, and sens3. The calibration for sens1 and sens2 are identical, but the calibration for sens3 requires an extra parameter. My question is, "What is the best way to deal with three near-identical objects while still maintaining readability?"

My first thought, of course, was to use polymorphism. I would setup a generic Sensor object with a .calibrate(Parameters params) method where the Parameters class allows me to vary the number of parameters based on the calibration that I am doing. However, this leads to the following:

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

So that future people will need to know that one sensor is fundamentally different than the other two, but very very similar, it seems to me that the best thing to do is to subclass Sens1 and Sens2 in name only. In other words, make two sublcasses that don't modify or extend any behavior in order to have more logical class names. Remember, all three of these sensors are in the same package, so this data very often goes together. This changes the above code to:

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

where

Sensor1 extends Sensor {
}

Sensor2 extends Sensor {
}

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

Am I crazy for thinking this is a good idea? Is there a cleaner pattern I'm completely missing here?

Answer 1

As written (which may be oversimplified) it sounds like the Sensors are all the same in general behavior, but the Parameters for calibration are different.

If this were the only difference, and you are using a language with generics, such as Java (used below), you could generify the class by the Parameters, something like:

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

   abstract public void calibrated(CalibrationParameters parameters);
}

then a bunch of

public class SensorN extends Sensor<CalibrationParametersForSensorN> {

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

}

Caveat: typed without an IDE so there may be typos or errors...

p.s. Agree with Robert that better names would be, er, better. So a better concrete implementation would be:

public class Thermometer extends Sensor<ThermometerCalibration> {

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

}

Answer 2

Not if the best descriptive names for these sensors are Sensor1, Sensor2 and Sensor3. The numbers do not indicate any distinguishing characteristics between the sensors.

If the different classes denote different types of sensors, then different classes may be warranted. This is why we sometimes refer to classes as types, though the word "type" itself has a broader meaning.

PressureSensor extends Sensor
TemperatureSensor extends Sensor

Answer 3

I'm not sure if the calibration should be the responsibility of the sensor... I would consider creating 2 new classes. Something like SensorCalibratorBase, SensorCalibratorAdavanced. Then, I would create a specific instance of the calibrator based on the app state and feed the sensor instance to it's Calibrate function. Each calibrator would get the needed params as the constructor arguments.