I am working on a project where I have to monitor the status of an elevator. So far, my design looks like this :
We are using a third party library to read and monitor realtime values from the elevator's logic controller. A tag is an integer value in a memory register of the logic controller. For example, DM140 contains the elevator direction.
I use an adapters layer in order to keep my application domain isolated from the third party library.
In the domain, the ElevatorDirectionMonitor takes the ElevatorTag integer value and extrapolate the elevator's current direction and then notify its clients that the elevator's direction has changed. So far, so good.
Here's my problem. There will be a lot (a hundred or more) of informations to monitor from the elevator, like the current floor, the doors are opened/closed, etc. If I continue this way, I will have to do one monitor class for each information I want to monitor (i.e. an ElevatorFrontDoorStatusMonitor, ElevatorRearDoorStatusMonitor) and each of them associated with its own Observer interface. This means a lot of work. I've been trying to find another way to structure my application, but didn't found anything more "elegant".
The basic logic in each monitor class would be pretty much the same in all of them : listening for value change on an ElevatorTag instance, extrapolate the information from the new tag value and then notify the observers. The problem seems to come from the fact that each observer must have a different interface signature.
Does someone could suggest me patterns I should use or anything that could help me to simplify my design.
Thanks!
Aucun commentaire:
Enregistrer un commentaire