Abstract Messages vs. Abstract Actors (Zero Coupling)

[BrianGShea@NGC]

Started new Discussion from (http://decibel.ni.com/content/docs/DOC-37533)

This method of zero coupling actors relys on an Abstract Parent Actor of child actors to provide the Message API. Multiple Parent Abstract Actor Classes can be defined for different APIs within a single application.

Rather than creating A singal Abstract Message then many child mesages, this method defines one set of message VIs that are coupled to the Abstract Actor with Message VIs that are setup to be dynamic dispatch. Each child actor implements one or more of the dynamic dispatch methods as required.

The total number of classes will be lower than that of Abstract Messages. In this case, there are 1 Message Class for each Message VI and N Classes for Each actor. In the example of 10 Child Actors with 10 Messages each, the total numbe of classes would only be 21, 10 Message Classes, 10 Child Actor Classes and 1 Abstract Child Actor Class. This is 100 classes less than the Abstract Message Method employed by the Actor Framework Project Provider.

What does the community think of this method of Zero Coupling Actors?

What preformance issues/gains will this have over Abstract Messages?

I will post a Zero Coupled Example using this method shortly.

[AristosQueue (NI)]

The Actor Framework white paper defines a high coupling, a low coupling and a zero coupling mechanism for sending messages to caller. What you describe sounds awful like the low coupling solution. It is not a zero coupling solution because the sender has a particular abstract parent class as its intended receiver. The zero coupling solution works when you have totally unrelated hierarchies for callers.

Please read the description of the low coupling solution and let me know if that matches what you're proposing here.

[BrianGShea@NGC]

AQ,

Do you have a reference to this document?

Yes, you are correct, this is not Zero-Coupled in that sense, and I stand corrected on the misuse of the term.

What do you think in terms of efficiency and reduced class count?

[AristosQueue (NI)]

If you create a new AF project from the project templates (on the Create Project dialog), you'll get the version of the white paper in your new project that is up-to-date for your version of LabVIEW. It is also linked on the READ THIS FIRST page of this forum.

In terms of efficiency and reduced class count, I'm ambivalent. There are times when that matters and times when that doesn't. Over time, the overhead of classes has been reduced and continues to be reduced in future versions of LabVIEW. We're never going to hit the zero overhead of C++, but I do think we'll hit the minimalist overhead of C#. For my own work, I design the software as it should work and only adjust for performance if that turns out to be an issue. I find that it very rarely is.

If I truly need zero coupling, this is the best solution I know. If I am ok with low coupling, obviously that's easier to write (and will remain easier to write even if we get the new scripting abilities in LV 2015 that some folks in this community have been working on).

[BrianGShea@NGC]

Thanks AQ. I had not seen that in the documentation because I was not using SP1 of LV 2013 until Tuesday. I'm reluctant to update and for very good reasons. I had to spend about 2 to 3 hours on tech support before I finally figured out that a bug in SP1 and patch f2 was crashing my project, the recently removed f3 patch fixed my problem after I was sent a link to download.

But now that I'm up to date, I will review that doc.

The aspect of Abstract Actors that I like the most, is that I can simple override a Method rather than creating a new message class and message VI. I can force the developers to override some methods when functionality must be provided.

I can also use a CORE method when some action needs to take place in my control actor and then make a decision to call the CORE VI if required. This may be in violation of some Actor Methodology but, it has it usefulness.

[AristosQueue (NI)]

There are definitely times when the abstract actor is the better choice. In general, if I am writing a library for general distribution, I need a zero-coupling solution. If I am writing an actor as part of a specific application, the low-coupling solution is not only sufficient but desirable. Ideally we would have Interfaces instead of Classes to support this, but that is outside LabVIEW's capacities at this time.

[maxwellb]

Brian, could you provide a link to some more information about that bug you were affected by? I'm beginning the process of upgrading to 2013 SP1 right now.

[BrianGShea@NGC]

http://digital.ni.com/public.nsf/allkb/4415B312CC61449A86257C820053B65E

Item # 445639 and 473817 i Believe ate the main two issues

[BrianGShea@NGC]

Also watch out for this one:

320485

—

User Events Created from Objects Cause Broken Packed Library VIs

http://www.ni.com/white-paper/14490/en/