Object Oriented in Producer/Consumer

[Gab]

Hello Everyone,

I need litter suggestion about object oriented with Producer Consumer design pattern.

I have One MAIN program and Other 7 module that controlled (mean sending message or command by queue to module) by MAIN program and it has producer consumer design pattern.Now i want to convert this application into OOP but my doubt is if I will convert in OOP then each case in consumer loop is become a class(Command pattern).In such case I have more than 100-200 class in entire application.

is it good idea to have such big amount of class in application? or i misunderstand something?

looking forward to your suggestion.thanks

[smithd]

17 hours ago, Bhavin Gabani said:

is it good idea to have such big amount of class in application? or i misunderstand something?

It sounds like your plan would be to follow the actor framework approach, where each receiver is a class (7 module+1 main) and every message is a class (+100-200). Its definitely been done, and its a concept that NI supports given that actor framework ships in the product, but I personally wouldn't want to deal with that many classes in a project. Labview becomes significantly more unstable just by adding a single class, and both stability and (edit time) performance take a hit as you add more.

There are alternative half-way routes too...what benefits do you expect from OOP for your application?

 

Edited December 6, 2016 by smithd

[Gab]

Well by oop i would expect Modularity and by adding HAL(in OOP) gives Scalablility .I will not going to follow AF but I am trying to use Producer-Consumer and each case in Consumer loop become Dynamic dispatch. 

[Neil Pate]

I would second what smithd wrote.

What is your experience with OO in LabVIEW? Certainly trying to refactor an application to OOP is not a good place to start your journey I think.

[smithd]

17 hours ago, Bhavin Gabani said:

Well by oop i would expect Modularity and by adding HAL(in OOP) gives Scalablility .I will not going to follow AF but I am trying to use Producer-Consumer and each case in Consumer loop become Dynamic dispatch. 

The design of distributing code components among numerous self-contained processes is already geared towards the goal of modularity and scalability. Depending on how responsibilities are separated, these different processes could scale out (I need to handle 8 new devices so I launch 8 new loops) or  provide modularity (one of my devices changed over from a Tek to an agilent so I just need to swap out this one process). These benefits are similar to those of the more common synchronous OO code and both styles are related to https://en.wikipedia.org/wiki/Message_passing (see especially "synchronous vs asynchronous message passing").

What you're saying is that you want to layer the synchronous style of OO on top of what is (or is close enough to) the asynchronous style of OO. This is why I ask...what specific things do you want to do with LVOOP that you can't currently do with your existing design. The answer to that should give you an idea of how much LVOOP you might want to use to accomplish those goals.

To try to give an example rather than talking vaguely, actor framework has a few different goals and layers. (I am not the expert on it so I'd refer you to this document for a more official view.)
-It provides an interface for dynamically launching processes. In order for this to be generic, the developers went with an OO solution.
-It provides a mechanism for handling messages generically where each message is bound to a particular hierarchy of processes (eg mymessage might perform actions on myclass, myinstrmessage might perform actions on myinstrprocess, etc).
Actor framework combines the two but it sounds like you only want the second bullet -- unfortunately, this is where most of the class implementations are.

I mentioned half-way routes...one *example* is that you could implement something like this: have a class called "myStateInfo" and it has a "handleMessage" dynamic dispatch method which takes a string and a variant. In the "handleMessage" method, you have a case structure based on the string, and you use that string to perform whatever actions you'd like. In the "default" case, you call the parent method. This would give you some measure of reuse (you don't have to implement a message handler that your parent already implemented) but would only require 1 class per process. 

Edited December 7, 2016 by smithd

[Gab]

17 hours ago, Neil Pate said:

I would second what smithd wrote.

What is your experience with OO in LabVIEW? Certainly trying to refactor an application to OOP is not a good place to start your journey I think.

I have intermediate experience in OO that'y i am not prefer to have Actor Framework because i know about how learning curve of Actor framework.