An actor with LOT's of methods?

[wrkcrw00]

I'm working on a very large application using AF. We are using FlexRio products extensively, so each intantiation of the FPGA is being wrapped in it's own actor. Some of these FPGA use cases involve lot's of discrete, individual IO. For instance, one has 20 different control lines, each needs to be called individually. I'm debating on the best way to create methods for the actor. In one case, I can see creating a method for each function, which seems to me fits the idea behind OOP and methods. I would end up with over 30 methods on some of my actors. The other way I see would be to have a single method for changing the state of any one of these control lines, with one of the inputs of the method being an enum or string for which control signal to change. Thus I would only have ~10 methods total, but would have to wire in more stuff when calling the messages from higher level applications.

Looking for suggestions or different approaches or advice on actors with large sets of methods.

[CaseyLamers1]

My suggestion is to think about how difficult of a public interface (in AF I loosely would say this is the set of methods that you create messages to/from the actor) to the actor do you want. In one case it is difficult to navigate a large number of methods. In the other case it is difficult to work with a method with multiple inputs.

In either case I would strive to make the interface easy to understand. Could you come back to it 6 months from now and understand how to use it? Could you bring on a new developer and explain to them how to use it? Make sure you can answer yes.

Another question I have is whether you are designing a generic interface with the FPGA layer. I have done this as a regular class, not an actor. I then have the parent (abstract) fpga class in my actor's private data and the actor uses the class. My FPGA class has about 80 methods in it. My different projects reuse components, but get deployed to different cRIO chassis. When I move to a new chassis I need to write a new FPGA class, but I don't need to rewrite any of my components.

Good luck,

Casey

[AristosQueue (NI)]

I oscillate back and forth on this question. I don't think there's a good rule to guide here.

The single function often offers more programmatic control -- the ability to choose dynamically which control line to call. The plurality of functions offers more ability to add parameters specific to each line (should it become necessary) and often makes it easier to find call sites in the code when doing refactoring.

There is a third option: Create the core function that is generic and uses a parameter to pick the line and then wrap that funciton in N other functions, each of which hardcodes for a particular line. Then you can call either mechanism as needed. Personally, I rarely use this option as it seems to muddy the waters (I can't rely on the specific wrappers to give me a bottleneck if people could still be calling through the generic interface), but I've seen it used well from time to time.

In the case of the Actor Framework, the third option is more interesting. There are two variations:

1. Create the specific method VIs, one for each control line, but then only create a single message class that can call any of them.
2. Create only a single method but then create N message classes, one per control line.

The first variant offers your users a much reduced interface so they aren't wandering through a large palette to find the right method but still allows you a breakpoint specific to each control line.

The second variant offers your users an interface specfic for each control line, useful if there are parameters that need to be set specific to that control line, but funnels them down to a single function that you can monitor for all changes.

Which of the (now four) options is right for you is something you have to evaluate based on who is going to be using the API and what kind of maintenance you'll be performing on the system.

By the way, option 3.2 is sometimes referred to as "the smart enum pattern". If you create 1 message class per control line, you can think of the act of picking one of those classes the same as picking an enum constant value, but it gives you a way to pick that value and supply some additional configuration info specific to that enum value. It's a useful trick in other contexts.