My OOP Design - Good or Bad?

[Absurd]

I am sorry for the crosspost but I asked for a moderator to move my other post over. Anyway I was wondering if anyone could give me any criticism on a new type of OOP framework I am working on. Anything constructive is appreciated, thank you.

Framework Test - 04.zip

[Daklu]

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

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.

[Absurd]

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.

[Daklu]

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.