Jump to content

My OOP Design - Good or Bad?


Recommended Posts

Grr... I was almost finished with a response when I accidentally clicked a link and lost it all. :throwpc:

Here's the short version:

I'm assuming the framework part of the code is the two classes and the other VIs are the application part of the code. My first suggestion is to move the framework code into an lvlib and give it a meaningful name. That will help developers who are using the framework in their own applications.

The biggest issue I see is that the Engine and the application code are mixing responsibilities. The most obvious example is the Engine is responsible for creating the queues, defining the queue messages, and accessing the queue, but the application is responsible for creating the consumer loops and implementing the message handling code. You need to better define the limits of the framework's responsibilities. There are a couple options:

  1. Reduce the framework's responsibility to image layout calculations and rendering the image to a picture control in memory. Let the application manage the queues and do the actual UI updates. This provides more overall flexibility in how the framework is used but requires the application developer to write more code.
  2. Move the two consumer loops into a new Engine method and call that instead of having them on Main's block diagram. If you do this you'll be able to make a lot of the framework code private members of the library, which helps make the framework easier to use. The downside is that it also restricts what can be done with the framework unless the developer edits the framework code directly, which defeats the purpose of having a framework in the first place.

Link to comment

Thank you for the reply. I will have to think about what to do next here. My goal was trying to have a single top level wire to carry to the producers and the consumers; instead of a GUI queue wire and an Action queue wire are separate. I am not sure how to most cleanly make this break. The Engine has both the responsibility to run a queue containing multiple actions in order (linearly run tests) and in parallel taking test data and displaying it via a GUI queue. I am thinking I might be able to create another Class to sit inside the Engine which would contain the array of PictureIndicators and handle their grouped functions.

Link to comment

My goal was trying to have a single top level wire to carry to the producers and the consumers

I recently posted an example of a programming idiom I frequently use here. That might give you a better idea of how to separate the responsibilities.

If you want the framework users to only have to deal with a single top level wire (without branching) then you'll have to dynamically launch a vi to run in parallel to the user's application code. When it's wrapped in a class it's called an "actor object" or "active object." Searching the forums should (if Lava search cooperates) return several lengthy threads.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.