LVOOP Design Help

[jon_mcbee]

I have a problem I am trying to solve using LVOOP, it seems like there should be an established way to solve it but I have been unable to think of/find anything that works.  Here is a description, I dont have any code mocked up that I can attach, but if it would be helpful I can put some together.  I am writing a test executive that will test multiple families of devices.  Each family has the same set of commands, but the commands may be implemented differently (don't have to be though).

 

I have an abstract parent class called DUT, and have children for each device family.  I also have an abstract parent class called Message, with a child message class for each command in my command set.  This is where I am getting stuck.  All devices have the same messages, certain devices implement (structure and parse) certain messages differently.  It smells like I want to override based on both device type and individual message, but this is not possible.

 

I am hoping that someone can point out either where I went wrong, or what the logical next step would be.  If more information is needed, please ask questions and I will do my best to answer.

 

Thanks!

[Ravi Beniwal]

Can you divulge a bit more about your architecture? How are the messages consumed? Are you planning to "read" the command from the message class and then run some code in a case structure or do you want to use some form of dynamic dispatching within your DUT class hierarchy?

[drjdpowell]

Your Message class should have an “execute message” dynamic-dispatch method that has a DUT input.  Inside the execute method you call dynamic-dispatch methods of DUT.  So you can make child message classes that call different DUT methods, and child DUT classes that override those methods.

[jon_mcbee]

I see.  The Message parent class is abstract and its implementation of the "Execute Message" dynamic-dispatch method does nothing.  Message's children override (not extend) the "Execute Message".  An extra input is added to the "Execute Message" method for DUT class.  The DUT parent class has a dynamic-dispatch method for every child of the Message class.  The DUT dynamic-dispatch methods are embedded in their corresponding Message child override "Execute Message" method.

 

The trick to making this work is that the DUT parent class must have an abstract dynamic-dispatch method for every child class of the Method Message class, and the corresponding DUT dynamic-dispatch method must be embedded into the "Execute Message" override method of each Message child class.

 

Is there a name for this pattern?  Is this a pattern?  Or is this just common knowledge?

[MikaelH]

Maybe something like this:

 

DUT.zip

[jon_mcbee]

I admit I am not as well versed in UML as I should be, so I may be misreading your diagram.  I don't understand why the DUT class holds a reference to the Message class in its object definition.

[MikaelH]

This way every DUT owns/has a Message Class in its attribute.

A message class type (e.g. Type A) could be used by DUT Type A,B and C, and Message Type B, could be shared between DUT Type D,E,F

Look at the example to see how I implemented it.

I don't know your requirements, but this is one design I could think of.

[ned]

Is there a name for this pattern?  Is this a pattern?  Or is this just common knowledge?

Yes, there is a name: it is the Visitor pattern.

[drjdpowell]

The trick to making this work is that the DUT parent class must have an abstract dynamic-dispatch method for every child class of the Method class, and the corresponding DUT dynamic-dispatch method must be embedded into the "Execute Message" override method of each Message child class.

 

No, the DD methods are not per child class; they are just methods to do stuff (which the children can override).  Child DUTs can also provide new methods, and messages can be written that call them by casting the DUT input to the correct child class.

 

— James

 

Added later: here’s an example “execute” method (though called “Do.vi”):

 

 

“VI Display name" is the message; it calls two methods on “Logger Daemon” to complete its task.