You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While there are many different AIS message types, the features in IAisMessage are available in all message types. Although this fact is reflected in the hierarchy of concrete message types (all the various record types representing specific message types such as AisMessageType1Through3 and AisMessageType5 derive from AisMessageBase which implements IAisMessage) it is not reflected in the interfaces themselves.
This leads to the following slightly annoying situation. Suppose I have some source of IAisMessages:
the resulting navigationMessages makes it awkward to get hold of universal AIS features such as the MMSI.
navigationMessages.Subscribe(m =>Console.WriteLine($"Ship {((IAisMessage)m).Mmsi} status is {m.NavigationStatus}");
This code has had to cast the message to IAisMessage in order to use its Mmsi property.
The MMSI is a universal feature of AIS messages. (That's why it's safe for that code to cast all messages to IAisMessage.) This should be reflected in the various interface definitions. We should never have to cast back to an IAisMessage—the availability of those features should be reflected by the interface type hierarchy.
(Other fixed relationships like this should also be represented. For example, we define IAisMessageType1to3. Messages of this kind will invariably offer IRaimFlag, IRepeatIndicator, and IVesselNavigation as well as IAisMessage. This is not currently evident from the IAisMessageType1to3 definition, but it should be.)
The text was updated successfully, but these errors were encountered:
While there are many different AIS message types, the features in
IAisMessage
are available in all message types. Although this fact is reflected in the hierarchy of concrete message types (all the variousrecord
types representing specific message types such asAisMessageType1Through3
andAisMessageType5
derive fromAisMessageBase
which implementsIAisMessage
) it is not reflected in the interfaces themselves.This leads to the following slightly annoying situation. Suppose I have some source of
IAisMessage
s:and suppose I filter this down to messages that provide navigation information:
the resulting
navigationMessages
makes it awkward to get hold of universal AIS features such as the MMSI.This code has had to cast the message to
IAisMessage
in order to use itsMmsi
property.The MMSI is a universal feature of AIS messages. (That's why it's safe for that code to cast all messages to
IAisMessage
.) This should be reflected in the various interface definitions. We should never have to cast back to anIAisMessage
—the availability of those features should be reflected by the interface type hierarchy.(Other fixed relationships like this should also be represented. For example, we define
IAisMessageType1to3
. Messages of this kind will invariably offerIRaimFlag
,IRepeatIndicator
, andIVesselNavigation
as well asIAisMessage
. This is not currently evident from theIAisMessageType1to3
definition, but it should be.)The text was updated successfully, but these errors were encountered: