Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interfaces should inherit from IAisMessage #199

Open
idg10 opened this issue Jul 6, 2023 · 0 comments
Open

Interfaces should inherit from IAisMessage #199

idg10 opened this issue Jul 6, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@idg10
Copy link
Contributor

idg10 commented Jul 6, 2023

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:

IObservable<IAisMessage> messages = GetAisMessageSource()

and suppose I filter this down to messages that provide navigation information:

IObservable<IVesselNavigation> navigationMessages =
    messages.OfType<IVesselNavigation>();

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.)

@idg10 idg10 added the enhancement New feature or request label Jul 6, 2023
@idg10 idg10 self-assigned this Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant