GOOP vs LCOD?

[Bryan]

For those who don't know, LCOD stands for LabVIEW Component Oriented Design.

Quite some time ago, I read the book: "A Software Engineering Approach to LabVIEW" (By Conway Watts), recommended reading to me by JohnRH before he left our company to become a mountain man.

For those who don't know what LCOD is, it's essentially elaborate functional (LV2-style) globals that use an enum-controlled state-machine (commands... i.e. methods, property get/set commands) that can be used for data hiding and auto-initialization (1st call, invalid refnums, etc).

In the book, it talks about LCOD and modular LV programming, some interesting stuff. I've actually been implementing usage of it in LV projects I'm able to work on (unfortunately, being a TE in my company so far is only allows me about 25% time using LabVIEW at the moment). I've found it to be very easy to work with and manageable. All functionality is contained within one VI subroutine without having to pass around refnums and have multiple subVIs for a particular "module".

Now, I haven't had a whole lot of time to mess with or really learn GOOP or OpenGOOP, although I have been trying to follow it with what little time has been available. It definitely is a tool I'd LOVE to use, however, I've been finding myself reluctant to use it because of what little I know about it so far and the fact that it's not as "compact" as LCOD.

Has anybody used both, used hybrids of the two, am I just comparing apples to oranges or just not making any sense (it's early and my coffee hasn't kicked in yet)?

[crelf]

LCOD is essentially elaborate functional (LV2-style) globals that use an enum-controlled state-machine (commands... i.e. methods, property get/set commands) that can be used for data hiding and auto-initialization (1st call, invalid refnums, etc).

I think that comparing LCOD and GOOP is like comparing apples and oranges. Sure, both methods allow you to encapsulate data in a private way, but I can't see a way of instansiating objects using the LCOD method, which (for me at least) is the main reason to use OO (that's where the scalability comes in - check out this for an introduction). There's also several other benefits to OO, inlcuding the ability to use inheritance from parent classes, etc... That said, many (but not all) GOOP engines use LCODs in their object repositories, so you could argue that OO extends the LCOD paradigm even further...

[JDave]

I think that comparing LCOD and GOOP is like comparing apples and oranges. Sure, both methods allow you to encapsulate data in a private way, but I can't see a way of instansiating objects using the LCOD method, which (for me at least) is the main reason to use OO (that's where the scalability comes in - check out this for an introduction). There's also several other benefits to OO, inlcuding the ability to use inheritance from parent classes, etc... That said, many (but not all) GOOP engines use LCODs in their object repositories, so you could argue that OO extends the LCOD paradigm even further...

So at what point does a project become 'large' enough to merit using GOOP over something like LCOD?

[Michael Aivaliotis]

So at what point does a project become 'large' enough to merit using GOOP over something like LCOD?

I think that's the wrong way of looking at it. You either use GOOP or you don't. In this case size doesn't matter. If you are creating throw-away code, then sure, GOOP is overkill, but in any other instance it should be used. The reason people are afraid of it is because LabVIEW has never provided a good fully functional native implemetation of GOOP. Of course, the next release of LabVIEW should change all that. :thumbup:

[crelf]

So at what point does a project become 'large' enough to merit using GOOP over something like LCOD?

The size of the project is irrelevant - it's whether you can disseminate objects in it's architectural design, and whether thoose objects need to be scalable - whether you need the ability to instantiate them.

Size doesn't matter - at least that's what my wife tells me...

[JDave]

I think that's the wrong way of looking at it. You either use GOOP or you don't. In this case size doesn't matter. If you are creating throw-away code, then sure, GOOP is overkill, but in any other instance it should be used. The reason people are afraid of it is because LabVIEW has never provided a good fully functional native implemetation of GOOP. Of course, the next release of LabVIEW should change all that. :thumbup:

Throw-away code sounds so negative. I am not quite sure what code you are saying merits to be done without GOOP.

I am not afraid of GOOP as much as I am afraid of OOP. I have done a fair share of C++ and C#, and the work of building a superfluous structure around my code often seemed worthless. What I have heard of the GOOP development toolkits (with auto-code generation) gives me some hope here at least.

Without the use of GOOP I have built a couple sizeable applications in LabVIEW. With some good upfront design they have turned out to be scalable, flexible, and robust. On the other hand I have worked on a couple tasks where I could see a real benefit in switching to GOOP. The need just hasn't been big enough yet.

The size of the project is irrelevant - it's whether you can disseminate objects in it's architectural design, and whether thoose objects need to be scalable - whether you need the ability to instantiate them.

I think this is one of the main issues. I have dealt primarily with instrument control and data acquisition. Rather than objects I have independent agents that need to communicate with eachother and act on that communication. I see no real opportunity to gainfully implement GOOP here. Maybe I am missing something.

And after a brief trip through bidirectional time, I have seen (will see?) that shortly I will be hearing about exactly what I am missing.

[Jeffrey Habets]

I think this is one of the main issues. I have dealt primarily with instrument control and data acquisition. Rather than objects I have independent agents that need to communicate with eachother and act on that communication. I see no real opportunity to gainfully implement GOOP here. Maybe I am missing something.

Your agents fit very well in an OO-design.. They would become so-called Active objects, objects that spawn their own separate thread of execution using VI-server. I've used them on multiple occasions and it's a very strong concept.

[Michael Aivaliotis]

...the work of building a superfluous structure around my code often seemed worthless. What I have heard of the GOOP development toolkits (with auto-code generation) gives me some hope here at least.

Well yes, if you could develop using OO A&D techniques and not worry about programming the framework code required to support it, then would you not do that? Are you arguing against OO design in general, or against OO design in LabVIEW?

[Bryan]

dsaunders has pretty much written here what I've been thinking. I have nothing against GOOP. I've been using solely LCOD to this point and am trying to figure out if I should be using one or the other or a combination of both. I haven't had a chance to mess with GOOP too much to understand it completely.

One of my things is that LCOD keeps me from having to wire up and maintain a crapload of refnums.

I'm going to have to search around here and look at some posted examples of usage I guess.

[JDave]

Well yes, if you could develop using OO A&D techniques and not worry about programming the framework code required to support it, then would you not do that? Are you arguing against OO design in general, or against OO design in LabVIEW?

I guess my first response is just to agree with what Bryan wrote.

dsaunders has pretty much written here what I've been thinking. I have nothing against GOOP. I've been using solely LCOD to this point and am trying to figure out if I should be using one or the other or a combination of both. I haven't had a chance to mess with GOOP too much to understand it completely.

One of my things is that LCOD keeps me from having to wire up and maintain a crapload of refnums.

Let me explain my thinking, and thus history, a little more.

When I first came upon Labview a couple years ago I enjoyed the dataflow and graphical aspects of it, which appealed to the EE in me. As I became more proficient, I was impressed at the ease of code reuse. Some careful design and my VIs become generic, reusable chunks of functionality. Reusable code without writing a whole class hierarchy, this is great. As I had come from a world of C++ and C#, I was enamored with the rate at which I could produce code. No worries about syntax and linkages and namespaces :thumbdown:

The presence of queues and notifiers, as well as dynamically called autonomous VIs just hastened my departure from my OO past. Here I could write a state machine that communicates with other state machines and get some real work done. Having the LabVIEW runtime engine was just too nice.

When I came across GOOP for the first time, I honestly thought Cool! :thumbup: . I had not forgotten the capability and usefulness of OO. I had just gleefully cast it off when I jumped into LabVIEW programming. I looked into GOOP, found a "crapload of refnums" and decided I would come back to it later.

So now it is later. I am looking at GOOP, and it seems odd that the tune I am hearing is all GOOP or no GOOP. Having designed and implemented some IMHO good code without GOOP, it just seems ridiculous to say that with GOOP I could have done it better. I look at the code and just can't see it. For example, I realized I needed a new object in my app, and after copying the agent template I have and adding the necessary work code it took just 10 minutes to place the object into my existing architecture. The design was basically OO A&D but there is no need to instantiate new objects at run-time.

On the other hand, I look at some other code I have written and think, a little GOOP could help here. It is perhaps a bit too dogmatic to say that anything other than throaway code should be done with GOOP. There are tools that solve many problems without it. I am not arguing for or against OO. I recognize that it is very useful. It takes care of many issues inherently, allows for scalability, etc. It enforces good design, hopefully.

I have sobered a bit from my early reckless abandon. I want to incorporate and use GOOP, but I don't want to throw away what has worked so well. I have an open mind about GOOP. I just want to keep that open mind.

David

[Bryan]

...I want to incorporate and use GOOP, but I don't want to throw away what has worked so well. I have an open mind about GOOP...

Exactly my thinking. I've just been having a hard time explaining it.

[crelf]

...it seems odd that the tune I am hearing is all GOOP or no GOOP.

Odd indeed. The secret of designing an appropriate architecture is to know the possibilities intimately, and then be able to make an unbiased decision on which one(s) to use, and in what combination(s). I have know several LabVIEW developers who insist that OO is useless, and others that insist that all projects should be done in OO - frankly, IMHO, that's both shortsighted and ignorant. As always - pick the right tool for the job. Just because you really like your new screwdriver doesn't mean you should use it to drive nails.

It's also a great benefit to have knowledgable people around you that can give you their :2cents: on the pros & cons for each architectural paradigm in each specific situation...

[Bryan]

...t's also a great benefit to have knowledgable people around you that can give you their :2cents: on the pros & cons for each architectural paradigm in each specific situation...

That was my goal posting in here.

I've not spent much time in text-based languages. I started in LabVIEW, THEN started learning a couple text-based languages. OO has always interested me. I understand it, and yet, I don't... if that makes sense.

[crelf]

I understand it, and yet, I don't... if that makes sense.

Completely - I was the same, until I studied under Mikael H. from Endevo - then, suddenly, one day:

[bsvingen]

I use the LCOD principle in a very large application, and i use dqGOOP within the "LCODs" to pass data and references between elements at init (i could have used an ordinary queue without the goop around it, so the main reason was actually to be sure that i only had thin green wires instead of those ugly queue wires with different internals At init stage there are no speed considerations either so dqGOOP was the way to go).

Anyway, from a practical point of view, i still cant see the main benefit of "real" GOOP in LV when we have LCOD and named queues. The named queues take care of everything at initialization, enabling you to route data and references to "executables" very efficiently to wherever you want so that everything is sorted out before execution, and can be changed also during execution. The LCOD principle assures at least the same scalability as GOOP, i would say with more scalability, since all this can be done without the need for refs. Those refs in all GOOPS i have seen are managable if you only have max 5-10 objects or so, but with 50-100-200++ objects of different sorts, then the refs makes the whole thing impossible. In my opinion GOOP (as implemented in the current available packages) is scalable only in terms of expanding the application around those very few objects you may have in the first place, not in terms of expanding the set of objects within that application. I guess you can use queues to pass those refs around instead of ref-wires, but then you end up being terrible close to the starting point of LCOD and queues.

But, as other people have said, the right technique for the right job is the most importent consideration, and the more tecniques, the better.