LabVOOP Design Patterns, v1.0

[SPM]

QUOTE (Aristos Queue @ Apr 23 2008, 12:39 PM)

As for Bridge pattern in particular: This is a pattern that you can pretty much use as is from the Gang of Four book directly in LabVIEW. There's no special behavior or alternate implementation required. It is extremely similar to the Delegation pattern which is covered in the LabVIEW design patterns document.

Thank you for your help! On a quick look, the delegating class is similar in structure to the Abstraction class in Bridge, though the purposes of the patterns are much different. -S.

[Norm Kirchner]

It seemed appropriate to this thread to mention that the LVx framework is, as pointed out by Tomi, an implementation of the command design pattern.

Also, I bought a book that I would recommend regarding this topic

"Head First Design Patterns"

Very well put together and easy to read.

[Nikimathew]

The idea behind object-oriented programming is that a computer program may be seen as comprising a collection of individual units, or objects, that act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility.

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

Nikimathew

viral marketing

[Falevoz Y.]

The recent arrival of the ability to manipulate objects by reference should allow to simplify these design patterns, isn't it?

Yann

[Aristos Queue]

The recent arrival of the ability to manipulate objects by reference should allow to simplify these design patterns, isn't it?

None of the patterns documented in the document change a lick with the introduction of DVRs. Some of the other patterns from the Gang Of Four book might be more directly implementable, but they (generally) remain undesirable as any use of references in a dataflow program is subject to severe negatives, especially since most of the needs that the patterns serve can be done without references. I would hesitate -- strongly -- to call any pattern that uses DVRs "cannonical" unless/until it can be demonstrated that no dataflow solution exists.

[Falevoz Y.]

None of the patterns documented in the document change a lick with the introduction of DVRs. Some of the other patterns from the Gang Of Four book might be more directly implementable, but they (generally) remain undesirable as any use of references in a dataflow program is subject to severe negatives, especially since most of the needs that the patterns serve can be done without references. I would hesitate -- strongly -- to call any pattern that uses DVRs "cannonical" unless/until it can be demonstrated that no dataflow solution exists.

All right.

I was mainly thinking of singleton that is, in C++, implemented by a static pointer. I figured that we could do the same in LabVIEW with a ref stored in a private fonctional global. But I understand your arguments.

Yann

[Aristos Queue]

I was mainly thinking of singleton that is, in C++, implemented by a static pointer. I figured that we could do the same in LabVIEW with a ref stored in a private fonctional global. But I understand your arguments.

The singleton pattern is one folks have talked about a lot on this forum and others. I keep coming back to the thought that a singleton object in LabVIEW is simply an LV2-style global (aka uninitialized shift register) with some defined operations. It is mutex safe, optimized for dataflow, and easily written. With some clever expansions to how you pass parameters (i.e., operations as class objects instead of raw data), you can make a very robust singleton object without defining a class specific to the singleton data itself. And you can find all the places where it is being used, a trickier proposition with the DVR solution. I recognize that the infastructure that you have to put around an LV2-style global is heavier than many of us would like, but that's in some ways more of an editor problem than a language problem. We made a big deal of building a singleton object example that ships with LV, mostly because everyone expected us to have a solution there, but over time, I have become less satisfied with that answer. The concept of "singleton" means "pointing all operations to a particular address in memory." In a dataflow language, that can be better optimized and (hopefully) better implemented by centralizing calls to a particular set of wires, not pointing many different bunches of wires at the same data.

[Mark Yedinak]

The singleton pattern is one folks have talked about a lot on this forum and others. I keep coming back to the thought that a singleton object in LabVIEW is simply an LV2-style global (aka uninitialized shift register) with some defined operations. It is mutex safe, optimized for dataflow, and easily written. With some clever expansions to how you pass parameters (i.e., operations as class objects instead of raw data), you can make a very robust singleton object without defining a class specific to the singleton data itself. And you can find all the places where it is being used, a trickier proposition with the DVR solution. I recognize that the infastructure that you have to put around an LV2-style global is heavier than many of us would like, but that's in some ways more of an editor problem than a language problem. We made a big deal of building a singleton object example that ships with LV, mostly because everyone expected us to have a solution there, but over time, I have become less satisfied with that answer. The concept of "singleton" means "pointing all operations to a particular address in memory." In a dataflow language, that can be better optimized and (hopefully) better implemented by centralizing calls to a particular set of wires, not pointing many different bunches of wires at the same data.

I completely understand why you would insist on using data flow. It is an extremely powerful programming paradigm. However, there needs to be a good way for parallel tasks to access a shared resource. This seems to be very difficult to do using native LVOOP. I admit I haven't played too much with DVR yet but I can think of many examples of the need to access a single entity or instance of an object in parallel tasks. For instance, an applications log file. In a traditional producer/consumer architecture you would have one loop with an event structure handling the UI events and another loop containing a state machine for the consumer. Let's say I want to allow the user to enter a message into the log while the application is running. It would be nice for both loops to have access to the single log object to allow this. However if I branch the wires I can't do this. Yes both loops would be able to actually write something to the log but what if I change some attributes on the log object. Using strict data flow I have two instances of the log object (where the wire gets branched) and an action such as enabling or disabling the logging of events will only work for one instance, not the entire log itself. I see this as a perfect use of OOP programming but something that LabVIEW's data flow paradigm restricts. An object should not be viewed the same as a wire in my opinion. If I instantiate a chair I don't want two chairs a little later simply because I branched the wire. My object design expects this to be the same chair, not a clone.

[Aristos Queue]

Mark:

The problem of single access to data is not a problem for OO to solve. It is a problem whether your data is a LV object, an array, a cluster or just a lonely integer. The DVRs are an excellent tool in that toolbox, and they are what you should use for many "parallel access to the same data" type of problems. LV2-style globals are another such solution. Both of these are options with relative pros and cons. I'm not sure that we've found a truly "good" solution to the problem at this point -- and by "we" I mean the LabVIEW community including LV R&D and all of our users. I helped with the work on the DVR feature of LV, and I think it is a useful tool. But I think it has to be "use these when all else is a worse" solution, not a "this is the first thing you should reach for" solution.

As I have said many times in the past: LV needs references. There are things you cannot achieve without references. But you should still avoid using references!