Leaderboard

As ak_nz and drjdpowell have both said, it is perfectly fine to implement concrete code in an abstract class. This lets you make full use of inheritance to keep your project tidy and organized. "Rules" and "best practices" are established to guide you down a tried-and-true path, to maximize your chances of succeeding the first time you try. However, a set of rules will never cover all possibilities so simply following rules will not guarantee you success. As the software designer/architect, it is your job to decide whether or not it makes sense to follow a rule in a particular part of your project. Referring to the two quotes above, I'd say: "It's ok to inhibit parent behaviour if 2 out of 20 children need to do it, but not if 18 out of 20 need to do it. If 10 out of 20 need to do it, well... make a judgement call." I'll answer your question in multiple levels. Level 1: The definition of "Abstract" In OOP, an abstract method is defined as a method which has no implementation. Its purpose is to define an interface for children to follow, and it is the children's job to provide the implementation. An abstract class is a class that contains one or more abstract methods. An abstract class can contain concrete methods too. So yes, if you put code in your parent method, then the parent method is concrete, not abstract. However, this in itself doesn't make the parent class non-abstract. Level 2: The (lack of) necessity of "Abstract" From your original question, I gather that you're wondering if you need to keep your parent "abstract" in order to abide by some set of best practices, and your latest post suggests that you're no longer worried about this. To reaffirm: Many examples of inheritance show you an abstract common ancestor implemented by multiple children. However, there are no rules that say you must have an abstract common ancestor. You are free to have a fully concrete (and usable) class as your common ancestor if it makes sense to do so. Level 3: The (lack of the) concept of "Abstract" in LabVIEW Since you're interested in formal definitions and terminologies, I'll throw this in: LabVIEW does not support abstract methods in the traditional sense (yet?). As I said in Level 1, an abstract method has no implementation by definition. However, what people commonly refer to as "abstract VI"s do in fact have an implementation: This implementation simply does nothing. "Having no implementation" is not the same as "Having an implementation that does nothing". LabVIEW doesn't let you create a VI with no implementation. In other languages, your program cannot be compiled if you inherit from an abstract class but don't provide implementations for all of its abstract methods. This can be a useful way to remind developers to implement them. LabVIEW doesn't do this -- a LabVIEW program will happily run even if you call an "abstract VI". To work around this, what I did in a recent project was to implement pop-up dialogs in my "abstract VIs". This way, I'll get a message at runtime if I forget to implement something in a new child class a few months down the track. EDIT: LabVIEW programmers fulfil the purpose of abstract functions by doing 2 things: (i) Have a VI that does nothing, and/or (ii) select the "Require descendent classes to override this dynamic dispatch VI" option in the class properties dialog. See this post for more: http://stackoverflow.com/questions/391483/what-is-the-difference-between-an-abstract-function-and-a-virtual-function (Note that NI explicitly rejected the term "virtual" because it's confusing to talk about non-virtual-Virtual-Instruments, so they picked "dynamic dispatch" instead) At the end of the day, knowing terminologies is useful (and important!) when discussing concepts, but it shouldn't affect how you design your project. All the best!

Normalizing the communication bus (Ethernet/IP, ModbusTCP, Profibus, CAN, Flexray, UDP, etc.) is where I have found LVOOP to be useful. Could I do this without LVOOP? Certainly. Is it a good use of the LVOOP tool? I believe so. The hardware manufacturers I've been working with don't seem to have heard of SCPI or consider it outdated. The types of devices I've worked with are drives, particle counters, valve manifolds, remote I/O, and weather stations. Most of the hardware is from customers' approved components list.