To make a parent class, or not to?

[GregFreeman]

So i have a relatively simple test program I'm writing. This system has a device. I doubt this device will ever change, but I suppose it could. This may be a case of "what I want to do is not worth it"

 

I'd like to add an abstract parent class which defines the functions needed for this test. They would all be dynamic dispatch and must override so if the device ever changed, a new class could be written to inherit from the parent class and boom all functions would need to be overridden for this new class. Once they are, the program will still run as if the device was never changed. 

 

But, I don't know if with this necessary quick turnaround time it's worth writing a parent class for something like this. This may be a case of real world vs. ideal world but I just wanted some suggestions.

[GregFreeman]

I think this is my problem: I try to make things overly flexible. Such as asking "what if they use a different device" turns into "what if that different device is tcp instead of gpib or serial etc". And then I over engineer...

[ShaunR]

Well. You haven't really given much detail since if a parent class is too much hassle. I would guess anything else would be too.

However. There are some simple edge-case scenarios where you can make a flexible system that can be extended without writing additional code at all.

Consider a DVM that is CMD->Response for all operations. By defining a "translation" file you can convert operations to commands (or a series of commands) and expected results so that you can use a simple parser and just choose the file dependent on device. If a new DVM is used (but the tests are the same) then you just create a new translation file. You can extrapolate this technique for the tests themselves too. However. It all depends on the system, what you need to do and the complexity/flexibilty required.

None of that has to do with classes or VIs, however. It's more a design choice to abstract away hw dependencies from the programming environment.

[Daklu]

Do as much as necessary to ensure a solid design that meets your immediate (and perhaps close future) requirements, but not more.

 

I agree with neil, with one minor caveat.  Even if you don't implement code for unknown future requirements, it's good to think about them and guesstimate how much refactoring it will take to accomodate them.  Minor changes to your original design can sometimes make future refactorings much easier.

 

In your case it is very easy to replace a concrete class with an abstract parent class.  (Subclass the concrete class, create empty vis for all the dynamic dispatch methods, change the inheritance hierarchy so the subclass is now the parent class.)  Since this refactoring is so easy I don't see that you gain anything by implementing it now.

 

 

Such as asking "what if they use a different device" turns into "what if that different device is tcp instead of gpib or serial etc".

 

I'll choose a developer who asks those questions over one who doesn't any day of the week.  Those questions *need* to be asked.  I believe the tendency to overengineer is a natural part of learning the craft of software development.  It will decrease as you learn the costs and benefits of various designs.  Eventually instead of asking "should I implement x to allow future flexibility" you'll be asking "how hard will it be to refactor to x to allow future flexibility."

[GregFreeman]

Well. You haven't really given much detail since if a parent class is too much hassle. I would guess anything else would be too.

However. There are some simple edge-case scenarios where you can make a flexible system that can be extended without writing additional code at all.

Consider a DVM that is CMD->Response for all operations. By defining a "translation" file you can convert operations to commands (or a series of commands) and expected results so that you can use a simple parser and just choose the file dependent on device. If a new DVM is used (but the tests are the same) then you just create a new translation file. You can extrapolate this technique for the tests themselves too. However. It all depends on the system, what you need to do and the complexity/flexibilty required.

None of that has to do with classes or VIs, however. It's more a design choice to abstract away hw dependencies from the programming environment.

 Shaun, I think you are getting at what I was actually just thinking. For instance, this is all VISA communication (for now, and I expect that won't change). I was thinking of having a file then if the device changed, just update the commands in a file for that device, point the software at the file to be read, then send out the commands through VISA. Now I don't need a class for each device, I can just have a "VISA black-box device" which has a read and write that just wraps the visa read/write functions and sends out the appropriate commands

Edited February 6, 2013 by for(imstuck)

[JackDunaway]

This may be a case of real world vs. ideal world but I just wanted some suggestions.

 

This general question is well-characterized and addressed by YAGNI. My anecdotal advice, initially suspect all code as a liability, not an asset. No code is better than no code.

 

(***Edited, to link to en.wikipedia.org/wiki/YAGNI since BBCode apparently chokes on unescaped apostrophes in URLs)

Edited February 6, 2013 by JackDunaway

[ShaunR]

 Shaun, I think you are getting at what I was actually just thinking. For instance, this is all VISA communication (for now, and I expect that won't change). I was thinking of having a file then if the device changed, just update the commands in a file for that device, point the software at the file to be read, then send out the commands through VISA. Now I don't need a class for each device, I can just have a "VISA black-box device" which has a read and write that just wraps the visa read/write functions and sends out the appropriate commands

I've done it many times, even to the point of a complete scripting language for one client. It works well as long as you don't have to handle state too much and it is sequential. You end up with files of the form

CHECK_VOLTS, TCPIP->READ->MEAS:VOLT:DC?, %.2f Volts, 10, -10

Edited February 6, 2013 by ShaunR

[MikaelH]

This general question is well-characterized and addressed by YAGNI.

 

The beauty of using good OO design in your application is the ease of modifying the software, so I almost always use the extreme programming approach. And of course with a help of some tools It’s easy to modify the design.

...or...

Result:

[todd]

Add another vote for more code*. I have communications classes (actors, actually), that allow Byte or string messages to happen over a few different kinds of pipes. These get used in more than one project. Instrument-specific command-to-useful-string conversions are performed in their own classes. Yes, lots of code - but extremely useful, in my case.

 

* Actually, I start with the simplest possible architecture for initial learning, then bring up the "better" code on the side.

[JackDunaway]

Add another vote for more code*. I have communications classes (actors, actually), that allow Byte or string messages to happen over a few different kinds of pipes. These get used in more than one project. Instrument-specific command-to-useful-string conversions are performed in their own classes. Yes, lots of code - but extremely useful, in my case.

 

This sounds like a different set of business and technical parameters than "i have a relatively simple test program I'm writing...I doubt this device will ever change...I don't know if with this necessary quick turnaround time it's worth writing a parent class" 

[todd]

"Spec? This unit IS the spec!"

 

Hardware prototypes, iterating all the way to post-production tweaks of previous widgets. Com pipes can change. Byte format can change. And I need backwards compatibility - old hardware, kind-of-recent firmware, latest LV app test suite, add a new instrument to take the raw temperature instead of using the on-widget processor, ...  Every app has a pop-up parameter list with enums so users can choose versions for everything (or INI files for silent selection). Poster-child for DD, in my hardware-based mind.

[Daklu]

"Spec? This unit IS the spec!"

 

Heh heh... having developed software test tools in a consumer electronics development test lab, I know your pain. For better or worse it is a fairly unique environment most software developers never experience.  Churning out test tools that can accomodate both legacy products as well as the latest changes dreamed up by the product engineers is extremely challenging.  Throw in the lack of a product spec and test engineers who show up at your door every day asking for "just a simple change," and you either learn to encapsulate everything with even the smallest chance of changing in the future, or you go postal.  (Or you create buggy QSM code...)  I spent so long *in* that environment I didn't realize just how chaotic and reactionary it was until I left.

 

So while I agree "more code" is the better solution given the business requirements in your situation, in this case I agree with Jack and strongly suspect the OP isn't operating with the same set of requirements you have.

[GregFreeman]

So while I agree "more code" is the better solution given the business requirements in your situation, in this case I agree with Jack and strongly suspect the OP isn't operating with the same set of requirements you have.

Very true, I have a small paragraph telling me what the test is and the parameters to measure, that's it. Basically "measure this data." That is my requirement  . (Can you say, "T&M" anyone?). I have gone the route of modertately flexible, with some child parent relationships etc, allowing me to change more easily in the future should I need to. But, I haven't gone to all the great lengths to determine what will need to be DD, how much abstraction do I need, etc. For now, I think this will work just fine.