LabView Advanced Programming Techniques, SECOND EDITION ch10

443 10 Object-Oriented Programming in LabVIEW This chapter applies a different programming paradigm to G: Object-Oriented Programming (OOP). New languages like Java and its use on the Internet have created a lot of interest in this programming paradigm. This chapter explains the concepts that make object-oriented programming work, and applies them to pro- gramming in LabVIEW. This chapter begins with definitions of objects and classes. These are the fun- damental building blocks of OOP. Key definitions that define OOP are then presented which give a foundation for programmers to view applications in terms of their constituent objects. Once the basics of OOP are described, the first stage of objects is presented — object analysis. Fundamentally, the beginning of the design is to identify the objects of the system. Section 10.4 discusses object design, the process by which methods and properties are specified. The interaction of objects is also defined in the design phase. The third and last phase is the object programming phase. This is where the code to implement the methods and properties is performed. This type of structuring seems foreign or even backward to many programmers with experience in structured languages such as LabVIEW. Object-oriented is how programming is currently being taught to computer science and engineering students around the world. A significant amount of effort has been put into the design of a process to produce high-quality software. This section introduces this type of phi- losophy to LabVIEW graphical programming. Object-oriented design is supported by a number of languages, including C++ and Java. This book tries to refrain from using rules used specifically by any particular language. The concept of object-oriented coding brings some powerful new design tools, which will be of use to the LabVIEW developer. The concept of the VI has already taught LabVIEW programmers to develop applications modularly. This chapter will expand on modular software development. This chapter discusses the basic methodology of object coding, and also dis- cusses a development process to use. Many LabVIEW programmers have back- grounds in science and engineering disciplines other than software engineering. The world of software engineering has placed significant emphasis into developing basic © 2007 by Taylor & Francis Group, LLC 444 LabVIEW: Advanced Programming Techniques design processes for large software projects. The intent of the process is to improve software quality and reduce the amount of time it takes to produce the final product. Team development environments are also addressed in this methodology. As stated in the previous paragraph, this chapter provides only a primer on object design methodology. There are numerous books on this topic, and readers who decide to use this methodology may want to consult additional resources. 10.1 WHAT IS OBJECT-ORIENTED? Object-oriented is a design methodology. In short, object-oriented programming revolves around a simple perspective: divide the elements of a programming problem into components. This section defines the three key properties of object-oriented: encapsulation, inheritance, and polymorphism. These three properties are used to resolve a number of problems that have been experienced with structured languages such as C. It will be shown that LabVIEW is not an object-oriented language. This is a limitation to how much object-oriented programming can be done in LabVIEW, but the paradigm is highly useful and it will be demonstrated that many benefits of object-oriented design can be used successfully in LabVIEW. This chapter will develop a simple representation for classes and objects that can be used in LabVIEW application development. 10.1.1 THE CLASS Before we can explain the properties of an object-oriented environment, the basic definition of an object must be explained. The core of object-oriented environments is the “class.” Many programmers not familiar with object-oriented programming might think the terms “class” and “object” are interchangeable. They are not. A “class” is the core definition of some entity in a program. Classes that might exist in LabVIEW applications include test instrument classes, signal classes, or even digital filters. When performing object programming, the class is a definition or template for the objects. You create objects when programming; the objects are created from their class template. A simple example of a class/object relationship is that a book is a class; similarly, LabVIEW Advanced Programming Techniques is an object of the type “book.” Your library does not have any book classes on its shelves; rather, it has many instances of book classes. An object is often referred to as an instance of the class. We will provide much more information on classes and objects later in this chapter. For now, a simple definition of classes and objects is required to properly define the principles of object-oriented languages. A class object has a list of actions or tasks it performs. The tasks objects perform are referred to as “methods.” A method is basically a function that is owned by the class object. Generally speaking, a method for a class can be called only by an instance of the class, an object. Methods will be discussed in more detail in Section 10.2.1. The object must also have internal data to manipulate. Data that are specified in the class template are referred to as “properties.” Methods and properties should © 2007 by Taylor & Francis Group, LLC Object-Oriented Programming in LabVIEW 445 be familiar terms now; we heard about both of those items in Chapter 7, ActiveX. Active X is built on object-oriented principals and uses the terminology extensively. Experienced C++ programmers know the static keyword can be used to work around the restriction that objects must exist to use methods and properties. The implementation of objects and classes in this chapter will not strictly follow any particular implementations in languages. We will follow the basic guidelines spelled out in many object-oriented books. Rules regarding objects and classes in languages like C++ and Java are implementations of object-oriented theory. When developing objects for non-object-oriented languages, it will be helpful to not strictly model the objects after any particular implementation. LabVIEW does not have a built-in class object. Some programmers might suspect that a cluster would be a class template. A cluster is similar to a structure in C. It does not directly support methods or properties, and is therefore not a class object. We will use clusters in the development of class objects in this chapter. One major problem with clusters is that data is not protected from access, which leads us to our next object-oriented principal, encapsulation. 10.1.2 ENCAPSULATION Encapsulation, or data hiding, is the ability for an object to prevent manipulation of its data by external agents in unknown ways. Global variables in languages like C and LabVIEW have caused numerous problems in very large-scale applications. Troubleshooting applications with many global variables that are altered and used by many different functions is difficult, at best. Object-programming prevents and resolves this problem by encapsulating data. Data that is encapsulated and otherwise inaccessible to outside functions is referred to as “private data.” Data that is acces- sible to external functions is referred to as “public data.” The object-oriented solution to the problem of excessive access to data is to make most data private to objects. The object itself may alter only private data. To modify data private to an object, you must call a function, referred to as a method, that the object has declared public (available to other objects). The solution that is provided is that private data may be altered only by known methods. The object that owns the data is “aware” that the data is being altered. The public function may change other internal data in response to the function call. Figure 10.1 demonstrates the concept of encapsulated data. Any object may alter data that is declared public. This is potentially dangerous programming and is generally avoided by many programmers. As public data may be altered at any time by any object, the variable is nearly as unprotected as a global variable. It cannot be stressed enough that defensive programming is a valuable technique when larger scale applications are being written. One goal of this section is to convince programmers that global data is dangerous. If you choose not to pursue object-oriented techniques, you should at least gather a few ideas on how to limit access to and understand the danger of global data. A language that does not support some method for encapsulation is not object- oriented. Although LabVIEW itself is not object-oriented, objects can be developed to support encapsulation. Encapsulation is extremely useful in large-scale LabVIEW © 2007 by Taylor & Francis Group, LLC 446 LabVIEW: Advanced Programming Techniques applications, particularly when an application is being developed in a team environ- ment. Global data should be considered hazardous in team environments. It is often difficult to know which team member’s code has accessed global variables. In addition to having multiple points where the data is altered, it can be difficult to know the reason for altering the data. Using good descriptions of logic (DOL) has minimized many problems associated with globals. Using encapsulation, program- mers would have to change the variable through a subVI; this subVI would alter variables in a known fashion, every time. For debugging purposes, the subVI could also be programmed to remember the call chain of subVIs that called it. Encapsulation encourages defensive programming. This is an important mindset when developing large-scale applications, or when a team develops applications. Appli- cation variables should be divided into groups that own and control the objects. A small degree of paranoia is applied, and the result is usually an easier to maintain, higher quality application. Global variables have been the bane of many college professors for years. This mindset is important in languages like C and C++; LabVIEW is another environment that should approach globals with a healthy degree of paranoia. 10.1.3 AGGREGATION Objects can be related to each other in one of two relationships: “is a” and “has a.” A “has a” relationship is called aggregation. For example, “a computer has a CD- ROM drive” is an aggregated relationship. The computer is not specialized by the CD-ROM, and the CD-ROM is not interchangeable with the computer itself. Aggre- gation is a fundamental relationship in object design. We will see later in the chapter that an aggregated object is a property of the owning object. Aggregation is a useful mechanism to develop complex objects. In an object diagram, boxes represent classes, and aggregation is shown as an arrow con- necting the two objects. The relationship between the computer and CD-ROM is shown in Figure 10.2. FIGURE 10.1 Door Object Data Data Data Data Data Object Oriented Structured Programming With Globals FIGURE 10.2 Computer CD-ROM1 0..n © 2007 by Taylor & Francis Group, LLC Object-Oriented Programming in LabVIEW 447 10.1.4 INHERITANCE Inheritance is the ability for one class to specialize another. A simple example of inheritance is that a software engineer is a specialization of an engineer. An engineer is a specialization of an employee. Figure 10.3 shows a diagram that demonstrates the hierarchy of classes that are derived from an employee class. Common in object- oriented introductions is the “is a” relationship. A class inherits from another if it is a specialization or is a type of the superclass. This is a fundamental question that needs to be asked when considering if one class is a specialization of another. Examples of this relationship are engineer “is a” employee, and power supply “is a” GPIB instrument. When one class inherits from another, the definition of the class is transferred to the lower class. The class that is inherited from is the “superclass” and the inheriting class is the “subclass.” For example, consider a class employee. An engineer “is a” employee (please excuse the bad grammar, but it’s difficult to be grammatically correct and illustrate an “is a” relationship!). This means that the definition of an employee is used by and expanded by the engineer class. An engineer is a specialization of employee. Other specializations may be vice-presi- dent, human resources personnel, and manager. Everything that defines an employee will be used by the subclasses. All employees have a salary; therefore, engineers have salaries. The salary is a property of employee and is used by all subclasses of employee. All employees leave at the end of the day, some later than others. The function of leaving is common, and is a function that all employee subclasses must use. This method is directly inherited; the same leave function may be used by engineers, vice presidents, and marketing subclasses. All employees work. Engineers perform different jobs than human resource employees. A definition in the employee class should exist because all employees do some kind of work, but the specifics of the function vary by class. This type of function is part of the employee specification of the employee class but must be done differently in each of the subclasses. In C++, this is referred to as a “pure FIGURE 10.3 Administrative Assistant Employee EngineerManager Vice President Software Engineer © 2007 by Taylor & Francis Group, LLC 448 LabVIEW: Advanced Programming Techniques virtual function.” When a class has a pure virtual function, it is referred to as an “abstract class.” Abstract classes cannot be created; only their subclasses may be created. This is not a limitation. In this example, you do not hire employees; you hire specific types of employees. There is another manner in which classes acquire functions. If employee has a method for taking breaks, and normal breaks are 15 minutes, then most subclasses will inherit a function from employee that lets them take a 15-minute break. Vice presidents take half-hour breaks. The solution to implementing this method is to have a pure virtual method in employee, and have each subclass implement the break function. Object programming has virtual functions. The employee class will have a 15-minute break function declared virtual. When using subclasses such as engineer and the break function is called, it will go to its superclass and execute the break function. The vice president class will have its own version of the break function. When the vice president class calls the break function, it will use its own version. This allows for you to write a single function that many of the subclasses will use in one place. The few functions that need to use a customized version can do so without forcing a rewrite of the same code in multiple places. Inheritance is one of the most important aspects of object-oriented programming. If a language cannot support inheritance, it is not object-oriented. LabVIEW is not an object-oriented language, but we will explore how many of the benefits of this programming paradigm can be supported in LabVIEW. 10.1.5 POLYMORPHISM Polymorphism is the ability for objects to behave appropriately. This stems from the use of pointers and references in languages like C++ and Java (Java does not support pointers). It is possible in C++ to have a pointer to an employee class and have the object pointed to be an engineer class. When the work method of the pointer is called, the engineer’s work method is used. This is polymorphism; this property is useful in large systems where collections of objects of different type are used. LabVIEW does not support inheritance, and cannot support polymorphism. We will show later in this chapter how many of the benefits of object-oriented program- ming can be used in LabVIEW, despite its lack of support for object-oriented programming. Polymorphism will not be used in our object implementation in this chapter. It is possible to develop an object implementation that would support inheritance and polymorphism, but we will not pursue it in this chapter. 10.2 OBJECTS AND CLASSES The concept of OOP revolves around the idea of looking at a programming problem in terms of the components that make up the system. This is a natural perspective in applications involving simulation, test instruments, and data acquisition (DAQ). When writing a test application, each instrument is an object in the system along with the device under test (DUT). When performing simulations, each element being simulated can be considered one or more classes. Recall from Section 10.1.1 that © 2007 by Taylor & Francis Group, LLC Object-Oriented Programming in LabVIEW 449 an instance of a class is an object. Each instrument in a test rack is an instance of a test instrument class or subclass. 10.2.1 METHODS Methods are functions; these functions belong to the class. In LabVIEW, methods will be written as subVIs in our implementation. The term “method” is not indige- nous to object-oriented software, but recall from Chapter 7, ActiveX, that ActiveX controls use methods. Methods may be encapsulated into a class. Methods are considered private when only an instance of the class may use the method. Methods that are public are available for any other object to call. Public methods allow the rest of the program to instruct an object to perform an action. Examples of public methods that objects should support are Get and Set functions. Get and Set functions allow an external object to get a copy of an internal variable, or ask the object to change one of its internal variables. The Get functions will return a copy of the internal data; this would prevent an external object from accidentally altering the variable, causing problems for the owning object later. Public methods define the interface that an object exposes to other elements of the program. The use of defensive programming is taken to individual objects in object-oriented programming. Only public methods may be invoked, which allows objects to protect internal data and methods. Only the object that owns itself may call private methods. These types of functions are used to manipulate internal data in a manner that could be dangerous to software quality if any object could alter the internal data. As an example of using objects in a simulation system, consider a LabVIEW application used to simulate a cellular phone network. A class phone has methods to register to the system, make call, and hang up. These methods are public so the program can tell phone objects to perform those actions. Each method, in turn, calls a Transmit method that sends data specific to registration, call setup, or call teardown. The information for each type of message is stored in the specific methods and is passed to the Transmit function. The Transmit function is private to the object; it is undesirable for any other part of the program to tell a phone to transmit arbitrary information. Only specific message types will be sent by the phones. The transmit method may be a common use function internal to the class. 10.2.1.1 Special Method — Constructor Every class requires two special methods. The first is the Constructor. The Construc- tor is called whenever an instance of the class is created. The purpose of the Constructor is to properly initialize a new object. Constructors can effectively do nothing, or can be very elaborate functions. As an example, a test instrument class for GPIB instruments would have to know their GPIB address. The application may also need to know which GPIB board they are being used on. When a test instrument obje