We just reviewed this stuff via a virtual chat, summary of where we are...
We presently have Messages.ACU.Reply and Messages.IncomingMessage classes which have nearly identical message parsing logic. Leaving it as-is for now because Reply has a dependency on Device whereas IncomingMessage replaces that with a more generic IMessageChannel interface.
In next incarnation of this code, ^^ Reply will derive from IncomingMessage but doing so now would require us to retest existing code that parses replies (all of it?)
We have beginnings of OutgoingMessage in Messages.PD.Reply and yes, at some point that logic will be factored out into a more reusable OutgoingMessage base class. Leaving that as an exercise for the future
When this work is taken to its eventual end, we should end up with a Message base class, Incoming/Outgoing Message classes driving from that and then Incoming/Outgoing Command/Reply deriving from those. BUT... we should NOT need any of command- or reply-specific classes deriving from those. Actual command/reply types and their payloads will be handled by the set of classes in OSDP.Net.Model namespace. Messages are generic containers responsible purely for building/parsing byte buffers.
I updated the messages to use defined command types to remove the usage of numeric numbers in the classes.
My recommendation is to create the following base classes.
If it makes sense, use IncomingMessage and OutgoingMessage.