根据 SOLID 主体注册侦听器

Question

I'm practicing oop concepts these days. To figure it out I tried the below problem.

There is a sensor monitoring system. It is a simple system that prints a value, whenever a sensor has picked a value.

I tried to solve this problem according to oop and SOLID principals.

So I created an interface SensorListener

interface SensorListener{
    public void onValueUpdated(SensorTypes type, double value);
}

Then I created a Sensor class

public class Sensor {

    private int value;
    private SensorTypes types;
    private SensorListener sensorListener;

    public Sensor(SensorTypes types) {
        this.types = types;
    }

    public void setValue(int value) {
        this.value = value;
        sensorListener.onValueUpdated(types, value);
    }

    public void registerListener(SensorListener sensorListener) {
        this.sensorListener = sensorListener;
    }

}

For sensor types the enum is as below

public enum SensorTypes {
    TEMPERATURE, PH, HUMIDITY;
}

For the monitoring purpose I created a class SensorMonitor that implements SensorListener`

public class SensorMonitor implements SensorListener {

    @Override
    public void onValueUpdated(SensorTypes type, double value) {
        System.out.println("Sensor Name: " + type + ", Measure: " + value);
    }

}

Finally in the main method I mocked the sensor updated using a Thread ,

public static void main(String[] args) {

    SensorMonitor sensorMonitor = new SensorMonitor();
    Sensor temperature = new Sensor(SensorTypes.TEMPERATURE);
    temperature.registerListener(sensorMonitor);
    Sensor humidity = new Sensor(SensorTypes.HUMIDITY);
    humidity.registerListener(sensorMonitor);
    Sensor pH = new Sensor(SensorTypes.PH);
    pH.registerListener(sensorMonitor);
    Thread thread = new Thread(() -> {
        int i = 0;
        while (true) {
            try {
                temperature.setValue(i++);
                Thread.sleep(3000);
                humidity.setValue(i++);
                Thread.sleep(3000);
                pH.setValue(i++);
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                System.out.println("thread interrupted");
            }
        }
    });

    thread.start();

}

In this way program successfully works and prints the output in 3 second intervals.

Sensor Name: TEMPERATURE, Measure: 0.0

Sensor Name: HUMIDITY, Measure: 1.0

Sensor Name: PH, Measure: 2.0

I'm satisfied with the behavior because it does what it says. But I'm not sure whether this a correct oop way of implementing interfaces and whether up to which context is this application scalable.

For example as the SensorMonitor how can it know the details of currently operating sensors, and what sensors are in the monitoring process?

Can someone point out what are the pros and cons in my approach.

Is this conforms to SOLID principals?

I appreciate a more concise approach for this problem.

Answer 1

There's no way to tell whether a design is good or bad if there's no specific requirements. If you just wanted to be able to listen to new sensor values then your current design works.

One thing that's certainly flawed is that registerListener overrides the previous listener (if any) so that could have unexpected results from the client perspective: setListener would probably have made it more clear that's the expected behavior or throw an exception if registerListener is called more than once if it doesn't support more than one registration.

For example as the SensorMonitor how can it know the details of currently operating sensors, and what sensors are in the monitoring process?

Well obviously your design fails at solving this problem since the SensorMonitor isn't modeled as such and acts more simply as an independent "listener". You'd simply have to adapt your SensorMonitor concept for the new requirements.

public class SensorMonitor implements SensorListener {
    private final Set<Sensor> sensors;

    public SensorMonitor() {
        sensors = new HashSet<>();
    }

    public void startMonitoring(Sensor sensor) {
        sensors.add(sensor);

        // Note that Current `registerListener` implementation could break the monitor
        // since you could override the monitor's listener.
        sensor.registerListener(this);
    }

    public Set<Sensor> monitoredSensors() {
        return Collections.unmodifiableSet(sensors);
    }

    @Override
    public void onValueUpdated(SensorTypes type, double value) {
        System.out.println("Sensor Name: " + type + ", Measure: " + value);
    }

}

Now you could make the monitor more flexible by allowing to instantiate it with a SensorListener and you could implement a CompositeSensorListener to merge multiple listeners together, etc.

Like I said there's no good nor bad design when there's no specific problem to solve .