LabVIEW
What is your tolerance for placing things into clusters?
@yenknip wrote:
There are very few places I would use a cluster over a class.
Organising things into groups which use a common typedef cluster, is pretty much the definition of a methods of a class.
Nested clusters invariably lead to a hierarchical class based data structure. You can also avoid nested Cluster.SubCluster.Data bundle/unbundle operations by just calling a parent getData method on the child class.
Lastly, as I mentioned, is the access restrictions. Allowing access the whole bundle / unbundle data of a cluster is bad practice.
I typed a big long reply but I feel like I haven't used OO enough to give much of a reply. Let me just say that for me, whenever I replace a cluster with a class I always regret it and only see the extra work involved in managing and making it, over a typed cluster that can be made with one right click. That's not to say classes don't have their benefits, I hope no one makes that argument.
@Hooovahh wrote:
I typed a big long reply but I feel like I haven't used OO enough to give much of a reply. Let me just say that for me, whenever I replace a cluster with a class I always regret it and only see the extra work involved in managing and making it, over a typed cluster that can be made with one right click. That's not to say classes don't have their benefits, I hope no one makes that argument.
Oh I absolutely agree with the "each to their own" points of view.
There was a rather extensive and heated beer-fuelled discussion at the CLA Summit, purely about LVOOP. I think it's fantastic that professional opinions on both sides of the fence are valid enough to be taken seriously when designing a system.
@Ray.R wrote:
I create SET & GET Methods to pass values through objects. The initial overhead may appear time consuming, but you will save that amount of time over & over while the project scope increases...
I don't understand this. If my project scope increases I edit my typed cluster. It is very quick and all my data updates. I realize that methods can be created that do more then just a get or set, but again many times (practically all) this is all that is needed. Could life be made easier by creating methods to do custom work on my data? Yes I can see that. But then again a subVI can do the same thing. It is reusable and I edit the code in one location to make changes to it.
@Ray.R wrote:
Are you using a single cluster for all your code?
In LVOOP, I have a cluster for each class in the project. The project contains over 13,000 VI's. I haven't calculated how many cluster elements there are in total, but it's probably close to 1000 (spread over all clusters in all classes).
13k? I guess the load and startup time of such a project is by lunch?
/Y
@Ray.R wrote:
Are you using a single cluster for all your code?
In LVOOP, I have a cluster for each class in the project. The project contains over 13,000 VI's. I haven't calculated how many cluster elements there are in total, but it's probably close to 1000 (spread over all clusters in all classes).
I would hate to see such a cluster (1000 elements, probably 2 layers of nested clusters.. Yikes 😮 ).
The beauty is that there is a Superclass which allows me to tap into any of the objects in any portion of the code. It offers flexability. Plus the code is very clean and easy to read. Minimal wires. 🙂
I have many clusters. Generally each Actor has a BFC cluster that grows as the temporary data that that Actor needs grows. That Actors cluster isn't shared with anyone it wouldn't make sense to. It contains some private things, some temporary things, and maybe some things that can be shared. When I want that data to be available I can share it through global means to the rest of the application, or send it privatly through a message.
Why would I want all of this data available everywhere? I only share what that Actor should share. If I have a cluster with a file reference in it, it would be crazy to share that with the rest of the application so I don't. There doesn't need to be explicit rules saying what should be private, instead there are ways to share only what should be public. Only my File I/O Actor will have that reference and there is no need to put that into a class because only that Actor has that data, and that Actor can do whatever it wants with that data. Also very flexable, very clean code, easy to read, and minimal wires. 🙂 As a result the project contains less files too.
To re-iterate. LVOOP does offer some advantages (inheritance among others) But the real question (As posed by Bilko) Is "How big is your data structure?"
A Super class means you forgot to modularize your code and give just what the module needs to be conserned with and expose only what is needed at higher levels.
Lets take a peek at one chunk out of my current project
A fairly basic QMH (And yes in my copy there are some typedefs that were disconnected here for your benefit)
Its responsible for all logging on a specific project. Could I have implemented it as a Actor dynamically dispatching logger.class? Certainly! and I could even have sibling logger classes to log to csv atml, html, ............ ad nauseum. In this instance however TDMS is the only desired functionality AND the code will be maintained be non-certified developers when I leave. Classes and OOP in general scare them! They are scientinsts and engineers. But, (Pause for effect) I could have implemented this as an actor calling methods of "TDMS Logger.lvclass" WITHOUT changing a thing. The Class contract is enforced and limited to only those actions to be taken on TDMS files within the application it resides. And because the reference to the resource is only within this module nobody else can mess with the resource. Every log call must go through here! But, anyone can queue to here. Could I go 1 step futher and write abstactions to enqueue the various methods and create "Log API"? (If the project was much larger I would!) But This project is only a thousand or so vis that do a repetitive task involving mostly waiting and responding with simple motions that scientists do by hand today (For hours on end). (I bet there a re a few state machines in there somewhere too but I won't give you all my secrets)
