Architecture question: Classes vs Action Engines

[Neil.Pate]

Hi Experts,

I am about to kick off a new project, and am tempted to try out a new architecture. Unfortunately time is (of coure) quite limited so if I make a big mistake in my architecture I won't really have time to go back and refactor everything, so that is why I am doing some research before I start.

My current favourite design pattern is to separate most logical blocks into Action Engines that can then effectively take care of their own business. I like to wrap the Action Engines in a lvlib and then have Public and Private accessor methods.

This works really well, I can't think of too many problems other than a bit of extra work in making the Public methods.

Now, to me this is crying out for using a simple Class, no dynamic dispatching or inheritance or anything like that, just using the LV Class to provide similar public/private methods but having LV do the code generationof Public interfaces for me.

So, I have four real questions, which hopefully someone who has done something similar in the past can help outwith:

1) is this a use case a good choice for Classes?

2) in classes the data is on the wire, does this mean there is actually a copy of the data, or is it just some internal trick and its just a reference?

3) in my old architecture, I could just drop down one of the Action Engine public VIs anywhere in my code, but now if I use a Class I need to bring a wire down to the deepest subVI. Is this correct and does this generate copies of the data?

4) if I have to use a wire to reference my Class, what about if I have 10 Classes (all doing different things, not the same Class), can I bundle these together and use a single Cluster wire in my main VI, and if so is there a performance hit. (I don't expect the actual classes to have masses of information inside their Class data)

Look forward to hopefully getting some answers 🙂

Thanks!

[tst]

---

nrp wrote:

in classes the data is on the wire, does this mean there is actually a copy of the data

---

This is the crucial thing to understand about LVOOP - a class wire is no different from any other wire. If you fork the wire, you will get two separate objects, not a single one.

This means that unlike an action engine, you will need to wire the specific object you want into all the VI, thereby missing the entire point of an AE.

There are several things you can do:

1. Do something similar to the singleton example that ships with LabVIEW. This guarantees a single copy of the class, but still requires you to acquire it and use a wire.
2. Use the reference example. This is similar, except you can generate N instances.
3. Keep using your current method.

These are actually not that different from each other. Unfortunately, you can't create accessor VIs from a template, so you can't use that shortcut as is. If you use scripting, you can automatically edit the VIs to insert the code you want into them, but I haven't done this.

[Neil.Pate]

Thanks tst,

I don't really want multiple copies of my object, and the singleton example made my brain hurt! (baby steps here for me...).

The ability to just drop the Action Engine VIs is so, so convenient... but I really like the ability of the Class to automatically generate the skeleton code for the methods. I do normally use a template (or copy one of the similar method VIs) so this is not a huge problem.

[tst]

---

nrp wrote:

I really like the ability of the Class to automatically generate the skeleton code for the methods.

---

I like it too, but the problem is that it does NOT work with templates. It can only generate empty VIs into which you will have to place your code. This can get tiring rather quickly.

[Neil.Pate]

Hmm, I suppose.

Perhaps I will read up a bit more on it. Some people seem to swear by it so I wonder what the benefits are (assuming no inheritance and things like that)?

[tst]

---

nrp wrote:

I wonder what the benefits are (assuming no inheritance and things like that)?

---

 The main thing I dislike about action engines is that because you have a single VI you can't really have a different VI for each function. Sure, you could use a string or variant input to the action engine and build a set of wrappers, but then you're better off using something else which also separates the code into different VIs. The native solution is LVOOP. Other than that, LVOOP serves a different purpose than an AE - it doesn't allow concurrent access to a shared resource, it just allows you to build your own data type with its associated VIs.

[bfarley]

nrp,

Don't give up on singletons that fast, they really aren't that hard to understand.  We went down the LVOOP route about 8 months ago and I have found that the singleton design is invaluable.  You can call class methods anywhere in your program and always know that your class state will be consistent.  The only drawback is you need lots of vi's.  For every method in your (private) class, you need a corresponding public function using the Check out-Check in formulation.  If you have lots of methods - it can be tedious. 

In some cases we have modified the singleton paradigm by not making the class private and implementing a rule among the developers that access to the class will always be via check out - check in.  I will probably catch some flak here because this isn't a "true" singelton architecture, but a "singleton-only-if-everyone-plays-by-the-rules" architecture, but it has worked well so far and has saved hours of boring vi creation.

Bill F

[F._Schubert]

I haven't used LVOOP, as I'm working under 7.1 and I really miss it. But some theoretical thoughts about it, as a base use wikipedia

AEs are encapsulating the data, as do objects.

What I really miss is inheritance and interfaces.

Class/Object abstraction can be done with AEs and VI server.

But as others already put that word: singeltone seems to be important (I guess for hardware access), which is a big pro of AEs as they serialize access by nature. So my approach to the singletone design would be a mixing of AEs with LVOOP.

One of the advantages of LVOOP: it is more easy to transform code of other OOP languages into LV, such as xUnit framework implemented in VI Tester by JKI.

Felix

[Jim_Kring]

Hi Felix,

Thanks for the VI Tester plug 🙂

Aristos Queue did some interesting work using LVOOP objects as the data inside a generic functional global.  I don't have any links, off hand, but I'm sure that someone (perhaps AQ) can point you to them.

Cheers!

-Jim 

[Neil.Pate]

Thanks for all the comments.

Regarding the singleton, and need to preserve access to a piece of hardware, this is not really something that I would need to do.

My classes are more obscure. For example I would want an Admin class to store housekeeping information about the application, this class would probably not need very much intelligence (internal code),but for example in a Log Data class I would want to be able to open a reference to a file, keep it open, and be able to at whim call a Write public method which would append text to the file.

Taking this example a bit further, it would be cool to have the Log Data as a base reference class, and then have several derived (inherited?) classes which override the Write method with their own unique data format.

But I still don't know how to just call the class public method from anywhere in my VI hierachy without having a wire going all the way down. Having to wrap it in an LV2 seems like the wrong way to go as then I would probably need another set of accessor VIs and should just stick with the pure LV2.

So, how does a large application get done with classes? All the examples I have seen are fine for the simple things they do, but I really could do with some tips on how to architect a large application.