Community Nugget 4/08/2007 Action Engines

[Tomi_Maila]

---

@jarrod S. wrote:
It seems to me the entire FG would constitute a class, since a class is not only stored data but the functions that operate on that data. The cluster in the USR is your private data, since it obviously can't be accessed outside the FG without accessor methods.

---

It depends on the use case. There is no one single answer or solution to this question. FG and AE are just means to achieve something. The actual use case defines how they can or should be used. In object-oriented programming there is a concept called design patterns. Design patterns are standard ways to solving problems of particular types. Even if the same programming technique are used in two design patterns the patterns are distinct if the underlying problem to solve is different. I think functional globals and action engines are there programming techniques. There is not standard way to use techniques pre se. There may be or rather may evolve standard ways to use action engines and functional globals to solve object-oriented programming problems of particular types. But then the technique to be used should be selected based on the problem to be solved. In some problems an entire class can be wrapped around an action engine. In some other problems action engines can be used just like you are using them now. Everything is possible and the problem to solve should determine the solution to use. What I'm trying to say that there are many ways to use each technique and there are no right or wrong ways just different ways that suit to different problems.

Tomi

[Ben]

Tomi wrote "The easiest way would be to follow my blog for some time. "

Why do I sense this reply is similar to the exchange:

----------------------------------------------------------------------------------------------------------------

Q: So what is so great about getting a tatoo?

A: That is a really hard question to answer, but if you try it you will understand.

______________________________________________________________________

I hope LVOOP is really worth the pain. 

Ben

Message Edited by Ben on 04-09-2007 01:53 PM

Message Edited by Ben on 04-09-2007 01:54 PM

[Tomi_Maila]

---

Why do I sense this reply is similar to the exchange:

----------------------------------------------------------------------------------------------------------------

Q: So what is so great about getting a tatoo?

A: That is a really hard question to answer, but if you try it you will understand.
___________________________________________________________________

---

Perhaps it's just my inability to compress the required mindset to few sentences. I however think a more appropriate comparison would be the following:

Q: So what is so great about programming with LabVIEW?
A: That is really hard question to answer, but if you try it you will undestand. 😉

Tomi

[Tomi_Maila]

---

I hope LVOOP is really worth the pain. 

---

OOP has a proven track record among other programming languages but LVOOP is different in many respects from these other object-oreinted programming languages and the answer to your question remains to be seen.

[Wayne.C]

Ben,

Nice one!  Thanks for taking the time to put this together.  For some dumb reason I never considered the sub-vi part. 

This almost makes up for the "disregard". 

[Ben]

Aristos,

I am reading and will continue to read.

Everyone,

I am glad y'all are bringing up performance. AEs (when properly implemented) can work in-place for many operations. Since the USR's buffer can can be our "working data space" AEs can burn! Unfortunately I thought AE performance tips and techniques was beyond the scope of this Nugget.

ohiofudu, Matt, others,

Thank you!

Kevin,

Exactly!

Anyone out there want to post an example of how to use the first call to force an init of an AE and then perfoming the selected action?

Lynn,

That method is great for tracking a change. When ever a check queue status combined with ared does not fit the bill, an AE of the type you mentioned can be used AND add reciept confirmation while you are at it.

DF,

"If I have a chance, I will code it up and post it. "

OH yes please do.

Jarrod,

You were starting to make sense until ...

centerbolt,

The disregard thread was my first attempt at starting this thread. I could not post the entire Nugget in one post so I had to stop and rethink the format.

"Sometimes you get the bear and sometimes the bear gets you."

Ben

[altenbach]

I guess the desingnation "Action Engine" will stick around as an official term. We should formulate a simple glossary entry that describes the core concept in as few words as possible.

---

@Ben wrote:

"Sometimes you get the bear and sometimes the bear gets you."

---

Hey, now even you icon makes sense! 😄 (Fortunately a teddy is not a grizzly.) 😮

[shoneill]

Nice nugget Ben,

Data hiding, standard interface, loose coupling, tight cohesion.

All typical characteristics of component programming.

Personally, I tend much more towards component programming than to object-oriented programming.  Never did really understand the fuss about OOP myself.  Re-usable code can be made in so many different ways.  The introduction of a specific interface with hidden data (compartmentalisation) also makes it easy possible to use distributed systems (seperate CPUs, even seperate computers on a network) to work on certain code.

I've been working more and more in this direction in the last time.  Powerful stuff.

Shane.

[Tomi_Maila]

---

All typical characteristics of component programming.

Personally, I tend much more towards component programming than to object-oriented programming. 

---

OOP and component programming can coexist and even often do coexist. Indeed OOP provides a way to implements components in a clean way.

[shoneill]

Of course they can co-exist.  Many of the principles defining OOP are present in Component programming (abstraction through interfaces, data hiding and so on).

Some things don't translate well, such as inheritance.  I personally find inheritance an unneccessarily complex way to describe simple code re-use.

They are two different approaches to a problem.  They do not need to co-exist.  Components can be fully non-OOP, and OOP can be fully non component based.

I have to admit that my lack of formal programming training leads me to believe I may be missing some important points, but for me they are two separate approaches.

"Indeed OOP provides a way to implements components in a clean way".  Without wanting to be provocative, "clean" is a point of view.  If I have trouble understanding OOP, an OOP implementation doesn't seem "clean" to me.  I think it's important to make clear that OOP isn't the "be-all and end-all" of modern programming.  Everyone should pick the approach which works best for them.

Shane.