Is this a good Use Case for LVOOP?

[ak_nz]

Hi All,

I am starting a new project and, being a relative new-comer to LVOOP (besides a little play-around with examples etc.), am wondering whether this project is a suitable use case for LVOOP ie. will I gain any advantages.The project scope is:

- Automated test equipment to test one and only one product type (ie. model). Tested using Labview for hardware interface and TestStand for sequencing the actual tests. This is unlikely to change (duplicating the entire equipment for a new model is more likely).

- Hardware interactions with the product are "one only" ie. there aren't several kinds of DMMs or SMUs etc. I have one of each type of hardware interface. This is also unlikely to change since changes to the product are unlikely. There will be around 8-9 hardware interfaces (read. PXI modules).

- The equipment is under a controlled system ie. change is a prolonged process, of which actual development is a very small part. Improvement in development time for modifications may not contribute to the total time needed for changes.

Besides encapsulation, I'm not sure LVOOP offers me enough advantages for this project, but I am interested in thoughts and ideas. An idea I have had thus far is implementing a simulation interface to each hardware layer (similar to the HAL concept) to allow me to perform unit testing of the architecture levels above but substituting in a simulation class, derived from a base class (eg. DMM_Simulation derived from DMM_Base) instead of the actual hardware-connected class (ie. DMM_Physical also derived from DMM_Base) by way of a the Factory Pattern. This is useful for development purposes but not practical use in production.

Thanks for any replies!

[JamesMc86]

Hi Ak,

I would encourage you to think about. I guess for specific reasons you have listed them. It will get you to build good modular code through encapsulation and the simulation part of HAL can be very useful. The other thing I would add is that no one thinks they need a safety net, but you can never know what the future brings and a HAL does give you more of a safety net.

I would also suggest if you are new to OO it is possibly good that you don't need any fancy design patterns. It can be a good project for you to get comfortable with the basics of implementation before getting stuck into a more complex design. My final argument would just be if you have objects in your system, might as well use OO rather than classes. EDIT: I mean clusters.

You can probably tell I am pretty keen on OO now!

Regards,

James

[ak_nz]

Hi James,

Thanks for your reply - I'll ponder this while I make the decision

[Daklu]

will I gain any advantages.

Yep, you will. Whether or not your project is better off by using OOP remains to be seen.

Learning good OOP design takes a long time and a lot of trial and error. You will make mistakes. I second what James said. If you put off learning OOP design until you need it, you've waited too long.

[ak_nz]

Thanks for your replies everyone.

I have been experimenting with using OOP with TestStand. I am using 2012 for both, so can directly access class methods in TestStand.

My strategy has been to have pre-defined hardwre objects (eg. DMM) that inherit from a Hardware_Base (with inherited dynamic dispatch methods Init and Close). I also have a static Factory Create method VI in this base class that creates, given a string, the required descendent object type that has been initiailised by a dynamic dispatch call to Init. Typical Factory Pattern. I can save the object references in TestStand and re-use Static methods VIs to operate on the class object (private data) to perform the necessary hardware functions. The base class also has a static method call that calls the dynamic dispatch method Close on the provided descendent object. This is all fine and dandy, and the classes allow me to provide a clean, encapsulated interface for unit testing purposes and minimising tampering of my interfaces.

Since I'm running a LabVIEW interface to house the TestStand ActiveX objects, I'd like to be able to access the object data from this interface (eg. DMM debug Panel showing the allowable private data such as configuration etc.). There seems to be no easy way to access the object without copying it, turning every object into a singleton or removing the object concept entirely (such as posting changed data via UIMessages, generated in a seperate, continuous TestStand thread). I'm sure there must be a way to eat my cake too...