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.

As the third topic in my article series Introduction to Object-Oriented Programming in LabVIEW I’ll talk about inheritance and conceptual hierarchies in object oriented programming.

Hierarchies of real-world objects

Object of the real world often form conceptual hierarchies. For example a bicycle, a motorcycle and a car are all examples of different kinds of vehicles. A bus, a truck and an SUV are examples of different kinds of cars. These relationships between similar objects can be visualized using diagrams similar to one below.

All vehicles share common properties and common functionality. For example all vehicles have one or more wheels and they are designed for transportation purposes. We can also fairly safely say that all vehicles have some sort of steering method.

All cars share even more common properties and common functionality. A steering wheel is used for steering the cars. An engine is used as a power source. All cars have at least four wheels and the wheels are symmetrically distributed on both sides of the car.

We can say that the word vehicle defines a class of real-world objects for transportation and so does the words car, bicycle and motorcycle. As cars, bicycles and motorcycles are all special kinds of vehicles as well we can say that words car, bicycle and motorcycle all define subclasses of class vehicle. In a similar way bus, truck and SUV can all be considered subclasses of class car as they are special kinds of cars.

Class hierarchies in object-oriented programming

It’s often the case that the building blocks of a software project form similar conceptual relationship hierarchies. Consider for example the following build-in LabVIEW types.

All of these build-in types are numeric types. Furthermore EXT, DBL, SGL, CXT, CDB and CSG are floating point numbers whereas I64, I32, I16, I8, U64, U32, U16 and U8 are integer numbers. We can divide integers to signed and unsigned integers and floating point numbers to real and complex numers. Indeed these numeric types can be considered to form a conceptual hierarchy similar to one below.

Object-oriented programming allows the developer to specify this kind of conceptual hierarchies in software architecture. Each box in the above image can be considered to be a class. Remember from my last article that classes are building blocks in object-oriented programming that encapsulate both data and functionality.

This concept of hierarchies is called inheritance in object-oriented programming. The word inheritance comes from the fact that the classes in the hierarchy inherit properties, functionality and interfaces of their parents and all other ancestors. The diagram itself is called a class diagram as it represents the relations between different classes.

Conclusions

In object-oriented programming developers can define class hierarchies that define the relations of classes. Decedent classes inherit the functionality, the interface and the data type of all the ancestor classes. Although it didn’t yet become clear, class hierarchies and inheritance is one of the key substances in object-oriented programming. Class hierarchies greatly enhance code reuse and allow creating more intuitive software architectures.

In my next article I’ll go into more detail what are the benefits of inheritance. Subscribe to the RSS feed so you will not miss it.