1

Problem Statement

I am going to write a library to control a whole bunch of relays, and I am just trying to think conceptually right now.

Here are my design constraints:

  1. We have an exact number of relays that need to be controlled, and this number will never change (because once we build a board we will never add relays).

Here is my proposed architecture:

  1. Have a class that represents a relay.
  2. Each relay should have an Open method.
  3. Each relay should have a Close method.
  4. Have a class that represents the circuit board that will Open/Close all the relays.
  5. Have the class contain a bunch of public members (one for each of the fixed number of relays).

So, conceptually my implementation would look something like...

RelayBoard myRelayBoard = new RelayBoard();

// establish a connection with the board
myRelayBoard.Connect();

// close a relay
myRelayBoard.RelayFive.Close();

// open a relay
myRelayBoard.RelayFive.Open();

// disconnect the board
myRelayBoard.Disconnect();

I am debating whether I should actually be using encapsulation here. The following, are my reasons for not wanting to use encapsulation.

  1. I don't think so because there are a fixed number.
  2. I also don't think so because they don't contain any data, the relay class is just a means for controlling each one.
  3. Also, I would have to write methods CloseRelay(5) and OpenRelay(5)... This means that the caller would have to worry about what the name of the relay is, and that just doesn't seem as concise.

Question

My only question here is, should I use encapsulation and make the relays private instead? I would like answers to at minimum address the 3 concerns I have about using encapsulation.

1
  1. I don't think so because there are a fixed number.

You may have different boards. If you write different code for each board (i.e. in the style of board.RelayTen.), you'll more code to maintain. One way to contain this expansion of configurations is to use a common program with external configuration or maybe an internal configuration that is constrained to a single configuration class or file.

  1. I also don't think so because they don't contain any data, the relay class is just a means for controlling each one.

I would think that you would want to be able to test the state of the relay, and want to store the last command issued to the relay (e.g. Open/Closed), maybe even when it was issued. When the program is initializing you may want to know whether you have positively opened or closed the relay as yet, so some isInitialized state.

  1. Also, I would have to write methods CloseRelay(5) and OpenRelay(5)... This means that the caller would have to worry about what the name of the relay is, and that just doesn't seem as concise.

Ok, (a) board.CloseRelay(5) is worse than (b) board.RelayFive.Close(), but (c) board.Relays(5).Close(), is better than both (or (d) board.Relays[5].Close()). With (c) or (d), you have the best of both: you can index them when that is appropriate, and you can get a relay object from an index for passing as an object parameter when that is appropriate. Also, it may be useful to manifest an object that represents the set of relays (independent of the board) which can be done with (c) or (d).

  • Ahh that's a good point, I never thought of (c). In the case of (c) you really get the best of both worlds. I will still be able to have an object for the Relay, and it uses encapsulation as well. – Snoop May 6 '16 at 15:14

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.