Jump to content

Best Way to Handle Composition of Same Objects


Recommended Posts

I have been working on some basic experimentation with OOP and want to apply it to a project that I have wanted to do for a while.

At university I created a VI that would traverse a LabVIEW project, print a HTML page for each subVI etc. and then create a home page and link the pages together. It worked quite nicely but when I started to look at additional features or customisation I knew that it was not scalable enough and I would treat that as a prototype and start from scratch. That was 2 years ago now and I am finally looking at it again!

I thought back then that OOP is going to be the best way to approach this and it's a good chance for me to write a largish OOP application (I have used bits before and understand practicalities but not some of the higher level design priniciples). Attached is an initial class diagram which is currently fairly simple. The basic idea is:

  1. The project class to generate my ProjectItem classes (This will be the parent class for various item types).
  2. It will generate these as references (I want to only generate a single page for each project item) and store them in a dictionary. For this I have been told that variant attributes are actually highly optimised.
  3. I will use scripting or similar to find each items subitems (e.g. SubVIs) and generate an array of these references.
  4. As each subitem is found it will identify itself as a caller to that subitem.
  5. Then I just have to generate the pages...

My thoughts are that each project item will have an array of DVRs to it's callers and one for it's subitems so that any methods for generating pages should have all the information they need. This however is naughty according to LVOOP as it is a recursive type. I see 2 potential ways around this:

  1. The children of project items contain their own arrays of DVRs to project items. I believe this is allowed however it seems like I will then be repeating functionality accross these child classes.
  2. I can "override" LabVIEW and cast the DVRs to I32 or similar and do it how I want. The thing is in my experience that LV has often known better and when I have forced it to do something like that it has come back to bite me in the arse!
  3. Having just been doing a bit of reading, there may be a 3rd. Is this a case for some sort of delegation pattern?

I would be interested if anyone had any suggestions for best practice on this or whether there is another option that I am missing.

I have just thought of a 4th possibility would be rather than using the arrays of objects and dictionary would be to use a database implementation instead but that feels like overkill for this.

post-18067-0-19637800-1326541402_thumb.p

Link to comment

I don’t have enough experience to really comment, but…, this sounds overly complicated. References to ProjectItems already exist in labview as Refnums. True, they aren’t LVOOP objects, but one could easily do a simple wrapper (Library object contains a Library Refnum, etc.), allowing dynamic dispatch of new functionality. Projects and Libraries can be simple by-value collections of Project items. So what are these DVRs for? Why does a Project item need references to it’s callers? And why can’t it just have a by-value collection of its subitems?

I understand the need to not duplicate things like HTML pages, but that functionality can be hidden down deep rather than complicating the higher structure. Just have “Generate HTML page” look to see if the page for this item already exists and only generate a new one if it doesn’t.

Anyway, I may not understand what you are doing, but it does sound complicated.

— James

Link to comment

The reason I was looking at by ref is to make sure I have one object with all the information before generating the page. Part of the issue with the original code was it got complicated editing the existing pages. I figured it will easy easier to generate the whole page at once.

I suspect you may be right though that a I could be missing a simpler method!

(null)

Link to comment

FWIW, simpler is generally better IME and reuse of code -- or original code "ideas" -- as far as possible is also good. Simply moving to a byref implementation doesn't necessarily seem better to me but I'm sure others here would have a better sense of the utility and details of doing that. I'd follow up on the simple idea of:

Use the refs for dynamic dispatch and do the HTML collation/correction/printing down in the dirt.

It's an old unix scheme.... :shifty:

Link to comment

Hey Guys,

Thanks for your advice. I have been looking through the properties I have in the project API and it does appear I can get all of the callers/subVIs through that so I can remove those arrays.

I will still use OOP for dynamic dispatching but it will like be a wrapper for the existing objects.

(null)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.