Should I represent physical accessories of a system as classes in software?

Question

I am redesigning a system comprised of a data-acquisition unit and a lot of different sensors (voltage sensor, angle sensor, pressure sensor, etc.).

In the software domain model, there is a base Sensor class, from which every concrete sensor derives.

public abstract class Sensor
{
    public virtual String Name { get; }
    public virtual UnitOfMeasurement Unit { get; }
    public virtual int SamplingRate { get; }
    public virtual CalibrationModel Calibration { get; }
}

Every one of these subclasses represent a physical sensor sold by our company, and has a "hardcoded" value for each property. For example VoltageSensor has "Voltage" as Name, "UnitOfMeasurement.Volt" as Unit, "1000" as SamplingRate, etc.

The current problem I am trying to solve is this:

Each time that a new actual sensor hardware is developed and added to our portfolio, we need to do the following "shotgun surgery":

1. Create a new Sensor subclass;
2. Perform some scattered, minor changes on the rest of the system (due to depencencies, etc.);
3. Release an update to our client base.

As I understand, each physical sensor (the hardware) is a conceptual unit, and as such should be able to be "plugged" to a running system so that it doesn't need to be recompiled and redeployed. Since this is not what's happening, I wonder how could I achieve this "pluggability" and still keeping the polymorphic behavior that is working well so far (except for each time we need to change the portifolio).

Is there some "Configuration over Polymorphism" alternative design that I could take?

Answer 1

When there are a lot of sub-classes of a class which don't differ at all in their behavior (method implementations) and only differ in their values, it is often a good idea to represent them all with one class and read their previously hard-coded values from a configuration file, database table or other data source.

To add a new sensor type, you would then just have to add a line to the configuration. Recompiling becomes unnecessary and when your configuration is in a human-readable format it could even be done by someone without programming knowledge.

When you do it smart, you can even make it possible to re-read the configuration while the program is running, so an update doesn't even require to restart the program.