In our last topic in article series Introduction to Object-Oriented Programming in LabVIEW I explained how real world objects form conceptual hierarchies. This concept of hierarchies is also present in object-oriented programming where building block can have hierarchical relationships. This concept of hierarchical relationships of software modules in object-oriented programming is called inheritance, as explained last time.
Inheritance in practice
So what does inheritance practically mean in the context of object-oriented programming? Why would we like to define class hierarchies?
Let’s first define some concepts. When a class inherits from another class we call the class upper in the hierarchy a parent class and the class lower in the hierarchy a child class. Further we call parent, parent’s parent and all other classes up in the inheritance chain ancestor classes. Likewise we call all classes down the inheritance chain descendant classes. In the picture below these concepts are visualized for the class Car.
As we explained earlier a class in object-oriented programming is a user defined datatype that encapsulates both data and functionality. In comparison conventional LabVIEW data types only carry data. As classes are types in object-oriented programming, wires of class types are called objects.
Each class in object-oriented programming specifies some functionality. To implement this functionality the class developer writes a set of method VIs. The method VIs are an integral part of the class. In addition the class developer specifies some internal or private data type for the class. This data type is a cluster. Note that the unlike conventional clusters, this cluster can also be empty.
Reusing ancestor methods
So what’s all the fuss about inheritance? Inheritance allows a developer of the descendant class to reuse much of the code in any of the ancestor classes. If an ancestor class has a method public method VI, this method is available also in any of the descendant classes. Furthermore if objects of ancestor class carry data of certain type, then all the descendent classes carry similar data of the same type.
Let’s take an example. Consider a land vehicle class. As each land vehicle has wheels, we decide to specify that a land vehicle class cluster of private data is an array of wheels. Cluster of private data is a place where the developer specifies the data type that is carried by the wire. Now our all objects of Land Vehicle class as well as all objects of any of the descendant classes of Land Vehicle would carry array of wheels as private data. In addition descendant of Land Vehicle can carry other private data as well but they would always carry at least an array of Wheels.
We cannot fix the number of wheels as some vehicles such as bicycle has only few wheels and others such as a train have more wheels. Further we cannot add an engine to cluster of private data as not all land vehicles have engines. The picture below illustrates the private data of our Land Vehicle class.
Now we define a public method VI Add Wheel.vi to Land Vehicle class. This method would add a wheel to a vehicle. Now each descendant class of class Land Vehicle would also have these two methods automatically. Land Vehicle would be a kind of a template or a starting point from which we can now build different kinds of land vehicles such as a car or a bicycle.
Class Land Vehicle is a parent class of classes Car, Bicycle and Motorcycle. Now comes the interesting part. All these three classes can call the Add Wheel.vi method as if it was their own. The picture below illustrates this ability.
So by inheriting classes Car, Bicycle and Motorcycle form a common parent class Land Vehicle, we can share code related to adding wheels to different kind of vehicles between these three classes. The same generality cannot be achieved in classic dataflow programming with such an elegant way.
Passing descendant classes as arguments
Consider you want to travel from Paris to Berlin. Unless you want to walk, you would need a vehicle to take you to Berlin. However it could be an aircraft, a land vehicle or even a watercraft. So generally you could say that any vehicle could be used to travel from Paris to Berlin.
Similar way thinking can be applied to object-oriented programming. When any VI expects an input of general class type then any of its descendants can be passed as an argument as well. So should you have a VI Travel by Land.vi that expects an object of class Land Vehicle as an input, you can pass any object of any descendant class of class Land Vehicle as an argument. This is illustrated by the following picture. The VI expects a Land Vehicle (right) and we pass a Car which is a child of Land Vehicle (left).
In the previous example we showed how we can reuse ancestor method VIs in descendant classes. However this is not the only benefit of inheritance and class hierarchies. In addition to reusing ancestor class code, we can also pass descendent classes as arguments where ancestor class is expected. Alternatively we can create an array of different kinds of Land Vehicles as select one of the items in an array using index array.
Conclusions
In LabVIEW object-oriented programming or LabVOOP for short we developers can share parent or other ancestor class code between all the decedents of that class. This is a great benefit when software components with shared properties are needed. In my next article in this series I’ll talk about class interfaces, how the interfaces can be shared between classes in the hierarchy and how this greatly enhances software development process. Subscribe to the RSS feed of this blog not miss it.
Loading ...
(2 votes, average: 4.50 out of 5)
