In my last article I introduced some of the basic concepts behind object oriented programming. Today I continue this introduction by talking about code reuse and composition.

So what do we mean by code reuse? Quoting Wikipedia “Code reuse is the idea that a partial or complete computer program written at one time can be, should be, or is being used in another program written at a later time”. A traditional way in LabVIEW to reuse code is to write subVIs that are shared between many applications or multiple parts of the same application. SubVIs can be further packaged into libraries which contain multiple SubVIs handling different parts of some process.

Object-oriented programming takes code reuse a giant leap forward. The enhanced code reusability is built-in to the design of object oriented programming and was one of the main design goals of object-oriented programming. In my last article I did not mention code reuse. However the concepts I introduced in my last article are central for writing reusable object-oriented code.

Today I’ll concentrate on two concepts of reusing code in object-oriented programming. First code reusability is very much a design issue. In object-oriented programming reusable design is enforced by forcing developers to encapsulate the data and the methods for manipulating the data together into joint entities called classes. As a result programming interfaces become cleaner which as a result increases code reusability. In addition the object data is hidden from the users and only exposed via interface methods forcing developers to think how they classes expose their data to maximize reusability. Second existing classes can be used as private data members of new classes with similar functionality. This way the functionality of a new class can be partially or fully delegated to some other classes.

Object-oriented programming also introduces a powerful technique called inheritance that helps reusing code a great deal. It’s a topic of its own, and we’ll leave it as a subject for our next articles.

Designing Reusable Class Interfaces

Although object-oriented programming provides many ways for reusing code, it doesn’t mean that code is automatically reusable. Writing well reusable code requires both experience and a lot of consideration from the developer. An important phase of object-oriented development process is defining the interface for the class under development.

Last time we talked about class interfaces. An interface consists of a set of methods (subVIs) the class user can use to perform actions on an object of that class type. These methods can be for example manipulations of the object private data, getting information about the object state or interacting with other objects or other systems such as files, devices and network. When defining this interface, the developer should think carefully how to make these interface methods as general purpose as possible to allow the class to be used also outside the scope of the current application in development.

In the development process the development team should really concentrate on defining and specifying the central parts of the interface of each class. If the interface of a class is only an implicit result of coding and not a design decision, the code reusability will definitely be scarified.

Composition

If a class interface is well designed, the class may be easily used to implement some of the functionality of another class. This can be achieved by using an object of one class type as a private data member of another class. Using classes as private data members of other classes is called composition.

As an example consider a class Engine that represents an engine of a motor vehicle. The interface of Engine has methods Start Engine and Stop Engine. Now consider you would like to create a class Car. Cars normally have engines so you can now use the class Engine as a private data member of class Car.

You may want the interface of class Car have methods Start Car Engine and Stop Car Engine. Now that Engine is a private data member of class Car you can delegate the actions of starting and stopping the engine from the Car class to the Engine class.

Composition is a very powerful and flexible way of reusing existing code. A new class can be composed of multiple different classes. One class could be used as a private data member multiple times in the same class. In our example class Car could have an array of objects of class Wheel in addition to class Engine as its private data members. Composition even allows changing the underlying implementation at runtime but we will not go deeper in to this dynamic composition yet.

Conclusions

Object oriented programming brings code reuse to completely to a new level. Indeed better code reuse may be the single most important reason to migrate from conventional LabVIEW programming to object-oriented LabVIEW programming. In this articles I’ve introduced several mechanisms of code reuse in object-oriented programming. These seemingly simple concepts are however hard to master. In my future articles I’ll go into more detail how to master these techniques.

In the next article I’ll introduce third mechanism of code reuse called inheritance. Subscribe to the RSS feed not to miss it.

Although object-oriented programming has been a standard method of software development for decades, it’s fairly new concept to most of LabVIEW developers. I start my blog with a series of articles introducing LabVIEW users to the concepts and ideas behind object oriented programming as well as to using object oriented programming in LabVIEW.

You may wonder why you should consider learning object-oriented programming. Well, there are a number of good reasons. Perhaps the most important reason why object-oriented programming has been so successful in the software industry is the fact that people are not very good at mentally managing very complex things. Object-oriented programming allows software architects and developers to divide the problem into more manageable pieces. The advantage is especially clear when working in teams. Each member of the team can concentrate on their own pieces of a complex software entity.

Object-oriented programming allows more modular software design compared to conventional dataflow programming. As a result of modularity object-oriented programming simplifies the modeling of the software architecture. Modularity also makes the software maintenance and management easier and simpler tasks. The software is more manageable throughout the entire lifecycle of the software.

Abstraction

The achieve software modularity object oriented programming relies on the concept of abstraction. The idea is that the software is divided into abstract and independent pieces that are easy to comprehend. Then the actual programming problem is solved using these abstract pieces without the need to know what happens under the hood of these pieces. The abstract pieces help programmers to describe the problem in terms of the problem and not in terms of the solution.

Whereas in traditional LabVIEW programming the abstraction is achieved using subVIs, in object-oriented programming the abstraction is achieved using objects. An object is an entity that fully describes the functionality and the state of something you want to abstract. Consider you want to abstract the concept of a car. An object car would then fully describe the functionality available in the car as well as the state of the car such as color or velocity.

In traditional dataflow programming each wire is of certain type such as a number of type DBL or a cluster composed of a string and a boolean. In a similar way in object-oriented programming in LabVIEW each object is of a certain type, or to be more specific of certain class. Classes are complete definitions of object types in a similar way as typedefs are complete definitions of traditional types.

Interface

Each object in object-oriented programming has an interface that complitely describes the functionality of the object that is available to the user of the object. In LabVIEW the interface is provided with a set of VIs that belong to certain class. Consider for example that you have a class Light that is an abstraction for a light similar to the one on your office table. You can turn on and off the light as well as adjust the brightness of the light. To implement the Light class in LabVIEW, you would need to create a new class called Light.lvclass. You could then define the interface of the class by creating four VIs: on, off, brighten and dim.

Hiding the implementation

When projects become so large that a single person cannot be responsible for the whole project, object-oriented programming becomes a handy tool. In such projects certain developers or class developers can be given a responsibility of developing certain classes. Other developers or class users then use these classes to solve some programming problems.

The interface of the class completely determines how the class user sees the class. The class developer should hide every VI that belongs to the class but that doesn’t belong to the class public interface. The interface VIs should be the only thing exposed to the class user. This concept of hiding parts of the class that do not belong the interface is called hiding the implementation. LabVIEW provides a way to set the visibility of each item belonging to a class from class properties.

Why is hiding the implementation important. Internally very complicated classes can have very simple public interfaces. Hiding the implementation also hides the complicated implementation related issues from the class user and makes the class functionality easier to understand. The interface is something that the developers can agree on before the start of the actual development work allowing developers to work in parallel. Hiding the implementation also prohibits the class user from accidentally using internal parts of the class and this way allows the class developer to change and modify the implementation later on as long as the interface VIs stay the same.

Conclusions

In this article I have discussed the ideas and concepts behind the object-oriented programming and why it is a handy paradigm for software development projects. To summarize dividing the application into abstract pieces called classes make the software projects more manageable compared to subVI level abstraction. Objects are instances of classes and classes specify the type of objects. Each class has a set of public methods called interface that is exposed to the class user. All the rest of the class internal implementation should be hidden from the class user to allow changing the class implementation throughout the lifecycle of the class.

In the next article I’ll dive deeper into the world of object-oriented programming. I’ll talk about reusing classes and about inheritance. Please feel free to comment the article. You may consider signing up to the RSS feed to stay tuned with the forthcoming articles.

Welcome to expressionflow.com, a blog on LabVIEW and visual programming. This is my first post, so let me introduce myself. My name is Tomi Maila and I’m the author of this blog. Visual programming and especially LabVIEW programming language are both my work and my hobbies. This blog and this web site expressionflow.com will be about LabVIEW and visual programming. I’m intending to concentrate on subjects I’m the most competent in; using of modern programming concepts in the framework of visual programming and LabVIEW. I will not yet go into detail of what I mean with modern programming concepts but rather let the blog to speak for itself during the times to come. I welcome everybody to read and follow my blog. I hope you’ll enjoy!