OOP terminology Meaning of "Overide"

[AKA_TG]

I have had trouble understanding this term over many years of trying to understand OO in LabVIEW. Finally it was explained to me in that an overide is an extension of an existing parent implementation. In all the help files I never remember getting this tidbit but the LabVIEW OO course made this distinction (finally)

I always thought an override was achieved by providing a completely different implementation as compared to the parent' one.

Overide to me means replace or completely bypass.

This has caused me great confusion when trying to learn and transfer OO  to LabVIEW. In learning LVOOP it is very important that terminology be meaningful and crystal clear.

I wonder if I am the only one who had trouble with this word.

Why is extending an existing implementation called an overide?

Shouldn't it be called extension?  If this stuff in the gang of 4 book forgive me. I don't have that book yet.

[PiDi]

Hello AKA_TG

Frankly speaking, I have problem understanding your problem here 😉 Methods overriding is not some LV-specific magic, it is one of the basic principles of OOP itself. And it is quite simple one - you override (provide another implementation) the method from parent class. Wiki says it all: http://en.wikipedia.org/wiki/Method_overriding .

Saying that overriding is "extending existing parent implementation" is generally not true. You can however call parents implementation of a method when implementing this method in subclass.

[NIquist]

Yup, the semantics of OOP are rather confusing until you "grok" it.  Of course there would be no point to override or replace an entire class.  If it's that different you would make a new class and call it something else, right?.  Methods in a class are what you override and IMHO override is the most appropriate word in that case as the overall class itself is still there, only some of its specific methods are changed to provide new behavior(s).  Also the word extension is already used as a way to partially override a method so... 

I know, MORE semantics!

[Intaris]

---

@AKA_TG wrote:

I always thought an override was achieved by providing a completely different implementation as compared to the parent' one.

Overide to me means replace or completely bypass.

---

This is correct.

[AKA_TG]

snippet of wiki description

Method overriding, in object oriented programming, is a language feature that allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes. The implementation in the subclass overrides (replaces) the implementation in the superclass by providing a method that has same name, same parameters or signature, and same return type as the method in the parent class

My Q is Why is the parent implementation included in the overide in LabVIEW when you ask for one?

The inclusion of the parent node implies that overide is an extension of the parents implementation.

The terminals are already part of the "so called" contract so why does LabVIEW include the parents implementation?

Another Q is why is dynamic dispatch Not considered an overide in itself?

Ill just listen in and try to learn here 🙂

[elset191]

---

@AKA_TG wrote:

My Q is Why is the parent implementation included in the overide in LabVIEW when you ask for one?

The inclusion of the parent node implies that overide is an extension of the parents implementation.

The terminals are already part of the "so called" contract so why does LabVIEW include the parents implementation?

Another Q is why is dynamic dispatch Not considered an overide in itself?

Ill just listen in and try to learn here 🙂

---

I don't know the reasoning behind including the parent call by default, but you are aware that you can remove it right?

For instance, In my child.save methods I call the parent.save so I don't have to write the code to save the parent data in every child class.  In this case I guess you could say it's 'extending' the method, but really it's overriding the method, and just happens to call the parent method.

Dynamic Dispatch and method overriding go hand in hand.  If you don't override a method, there is nothing to dynamic dispatch to.

[PiDi]

---

@AKA_TG wrote:

My Q is Why is the parent implementation included in the overide in LabVIEW when you ask for one?

The inclusion of the parent node implies that overide is an extension of the parents implementation.

---

elset191 answered it right: the ability to force overriding VIs to call parent method is LabVIEW feature and this can be turned on and off for every class method (go to class Properties -> Item Settings -> select class method -> check/uncheck "Require overrides of this dynamic dispatch VI to always invoke the Call Parent Method node").

---

@AKA_TG wrote:

Another Q is why is dynamic dispatch Not considered an overide in itself?

---

@dynamic dispatch and overriding are very closely connected, but there is a small distinction. Method overriding is the language feature. One can say this is the semantics that allows you to tell the compiler: "This method will have multiple implementations, specific to each class in the hierarchy". In C++ this is done implicitly, by creating method in subclass with the same name, arguments and return type. In Java you have to additionaly mark the method with keyword @Override. And in LabVIEW this is done by making connector pane elements to "Dynamic Dispatch Input/Output".

Dynamic dispatching can be understood as the technique - implementation of the overriding mechanism. Normally ("static dispatch" case) the program will know exactly what chunk of code should be executed when it will reach the class method - it will be "hard-compiled" into program. In dynamic dispatch case, the compiler cannot know, which method will be called exactly - it will depend on context (the calling class). So the decision is left for the run-time, when this context will be available.

So, to sum up: method overriding is the ability to say that I will implement the same method many times, and dynamic dispatching is the technique that the compiler use to implement method overriding.

Hope that explains your questions 😉

[NIquist]

If you're trying to come to terms with the basic, overall concepts of object oriented programming I sincerely suggest you study a dedicated book or web resource.  If you know another language like Java, C++ or Python play with those languages until OOP is comfortable for you.  LabVIEW's implementation of OOP is necessarily convoluted due to its graphical nature.  If you want to learn OOP specifically through LabVIEW look into the tutorials from NI.  There are some really good ones that show you both the traditional procedural code and then upgrade it to OOP.  I needed to read through them several times until I finally understood how to bring it all together. (I still have a lot to learn though!)

Don't try to force it.  Many people will tell you that they went around in circles with OOP until one day they got that 'AHA' moment and the light bulb went on. 

[AKA_TG]

"" 

---

elset191 answered it right: the ability to force overriding VIs to call parent method is LabVIEW feature and this can be turned on and off for every class method (go to class Properties -> Item Settings -> select class method -> check/uncheck "Require overrides of this dynamic dispatch VI to always invoke the Call Parent Method node").

---

Dynamic dispatch and overriding are very closely connected, but there is a small distinction. Method overriding is the language feature. One can say this is the semantics that allows you to tell the compiler: "This method will have multiple implementations, specific to each class in the hierarchy". In C++ this is done implicitly, by creating method in subclass with the same name, arguments and return type. In Java you have to additionaly mark the method with keyword @Override. And in LabVIEW this is done by making connector pane elements to "Dynamic Dispatch Input/Output".

Dynamic dispatching can be understood as the technique - implementation of the overriding mechanism. Normally ("static dispatch" case) the program will know exactly what chunk of code should be executed when it will reach the class method - it will be "hard-compiled" into program. In dynamic dispatch case, the compiler cannot know, which method will be called exactly - it will depend on context (the calling class). So the decision is left for the run-time, when this context will be available.

So, to sum up: method overriding is the ability to say that I will implement the same method many times, and dynamic dispatching is the technique that the compiler use to implement method overriding.

Hope that explains your questions ""

Actually it does!  Thanks to all for answering!

Took awhile to get up to speed with LVOOP, being a procedural guy for many years but it seems to be well worth the effort now that LV is stable enough to support LVOOP.

I wish I had time to learn how to be a heavy hitter C++ but it just is not going to happen , given my job description.

I read Allen Shalloway,s book Design Patterns Explained and I'd have to say that if anyone wants to learn OO without using C++ or Java this is the book to read.

His explanation of OO was clear and excellent. He actually shows how the patterns work without using java code examples.

If anyone has other OO books they really liked please chime in.

.