3

I have two objects which work together to provide interaction with HIDs on a machine. One object is responsible for the communication (read/write) to the HID and the other object is responsible for modelling the HID. Information is read and written to the HID as byte arrays.

As a contrived example:

class Hid
{
  private HidComms comms;

  public DateTime? GetPropertyB()
  {
    return comms.GetPropertyB();
  }
}

class HidComms
{   
  public DateTime? GetPropertyB()
  {
    // request property B from HID
    // get 1 or more byte[] in response
    return new DateTime();
  }
}

Which of these two objects should be responsible for encoding/decoding the byte arrays, or should a third object be responsible for this? Meaning the Hid object only knows about state and the HidComms object only knows how to read/write with a third object responsible for the conversion?

  • So Hid is an object in your logic, and HidComms is a helper class filled with the actual algorithms? – Nathan Cooper Jul 17 '14 at 14:57
  • @NathanCooper - Hid contains properties for a physical object and HidComms contains read/write filestream functions for communicating with a physical object. – Unflux Jul 17 '14 at 15:11
  • Encoding/decoding tents to be based upon an algorithm. The algorithm should have it's own class, and Hid uses that class so it's not tightly coupled to the algorithm. MD5 as an example would be in a MD5 class. – Reactgular Jul 17 '14 at 15:57
  • 1
    @MathewFoscarini - So to clarify something like; Hid makes a request for information via HidComms which returns byte[] in response. Hid then passes this to "Conversion" object which inspects the byte[] and returns to Hid an actual value? – Unflux Jul 17 '14 at 19:07
  • Yes, now your algorithms can change and Hid/HidComms don't need to be changed. – Reactgular Jul 17 '14 at 20:57
1

The best way to think of this is: what if you change your HID.

If your comms class handled the awkward aspects of translating a generic description into the byte arrays, then you only have 1 class to change. However, your Hid class might well be the primary object that interacts with the HI, and the hidcomms is solely there as a helper class to transfer the byte stream.

So.. it depends. From looking at the code in your question, I'd let the hid generate the byte arrays as it seems to encapsulate the entire HID.

  • +1 remember YAGNI: if other serializations become necessary, you can always factor the byte array logic out of the data class. But that's an arbitrarily large problem. In the meantime, Hid has an "asByteArray" method, and you get paid and can move on to other work. – Rob Dec 30 '14 at 17:17
0

The usual principle of encapsulation (that implementation detail should be confined to as little code as practical) applies here. The information about encoding and decoding the byte arrays should be restricted to one class without a good reason to share it further.

The more obvious way to arrange this is for HidComms to translate the byte arrays to and from some higher-level representation.

The less obvious way is for HidComms to handle (but not understand) byte arrays going to and from the HID, while Hid (or a third class) does the encoding and decoding.

Both approaches are equally valid. They differ mainly in how you treat encoding/decoding errors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.