We are using a third party library to read and monitor real-time 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, extrapolates the elevator's current direction, and then notifies 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 types of information to monitor from the elevator, such as the current floor, whether the doors are opened/closed, etc. If I continue this way, I will have to create one monitor class for each type of information I want to monitor (e.g. an
ElevatorRearDoorStatusMonitor) and each monitor 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 haven't found anything more "elegant".
The basic logic in each monitor class would be pretty much the same across the board: listen 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 class must have a different interface signature (e.g.
NotifyDirectionChanged(ElevatorDirection newDirection) when a
DoorStatusMonitor would rather have something like
NotifyDoorStatusChanged(DoorPosition frontOrRear, DoorStatus openOrClosed)).
Do you think that the solution I am working on is acceptable. If not,could someone suggest which patterns I should use or investigate, or anything that could help me to simplify my design?