The Language of Abstraction

Ethan Stern

This car is an automobile. It has four tires.

Say what you mean and mean what you say. As I delve deeper into the world of LabVIEW abstraction and SOLID code development, it becomes increasingly clear that language makes a big difference. We LabVIEW developers might recall some LVOOP primer where the presenter whipped out the old automobile class hierarchy example to convey the idea of inheritance (I'm guilty). It's an example simple enough to build a consensus of nods and let everyone leave the room clearly understanding that a car is indeed an automobile. In spite of its complete irrelevance to the code we write on a daily basis, I think there are a couple of reasons this is actually a useful example.

---

Is a...

For those with some exposure to object-oriented programming (in LabVIEW or elsewhere) you know that we use "is a" relationships to define our class inheritance:

• A Car is a type of Automobile.
  
• A Jetta is a type of Car.
  

With these simple statements, we have defined a hierarchy. As you can see, language is immediately important to our design.

Has a...

Just as "is a" statements guide us on defining our class inheritance, "has a" statements guide us in assigning data to our classes.

• An Automobile has an ignition.
  
• A Jetta has a seat warmer.
  

If we need some class data to support these features (on/off state, perhaps), we should, in general, assign them to the highest class type to which they always apply. Is there a possibility that some type of automobile does not have an ignition? Sure. Do we need to account for every possible automobile, including those yet to be invented by Dean Kamen, in our abstractions? Of course not.

A Method to the Madness

I think that properly naming methods (VIs in conventional LabVIEW-speak) is one of the most important factors in writing readable and maintainable code. The purpose of each special little (hopefully decorated) box should not be a mystery. A method called "Start.vi" should do everything necessary to start an Automobile. Its name should match its purpose. If this method is defined for an Automobile, it should apply to all children of Automobile, including (you guessed it) a Jetta.

There are two basic rules I try to follow when naming my methods:

1. With a few exceptions, include a verb and a noun. For example: "Initialize Log.vi", "Close Port.vi", or (with an adjective) "Launch User Dialog.vi". Very generic methods defined in an abstract parent class (like "Start.vi" in the Automobile class) are one exception.
2. Make the name meaningful and direct, but no more specific than it absolutely needs to be. For instance, I could have called "Launch User Dialog.vi" something like "Launch Continue or Quit Dialog.vi".  Why not? Suppose a child overrides this dialog in the future and adds a new ability I hadn't previously considered, like a Retry button. In that case, the child override would be improperly named.

Access Scope

When you follow one SOLID software design principle (SRP, for instance), others often fall out naturally. Similarly, if you give good thought to your abstractions and diligently apply good language (the speaking/writing kind), the mystery of access scope seems dramatically less mysterious.

Would my Jetta's ability to pair to a Bluetooth device (i.e. "Pair Bluetooth Device.vi") apply to all parent Automobile classes? It would not...so this method might belong as a Private member of the Jetta class we call only when a Jetta starts (inside Jetta: "Start.vi"). Just as using clean and intentional language helps other developers understand our designs, so does properly scoping our methods.

Im-ple-men-ta-tion

By considering language up front, we make things so much easier on ourselves. Since my methods are clearly named and cleanly organized within my classes, their purpose is also clearly defined. Does "Pair Bluetooth Devices.vi" also print a test report showing details about the pairing and, while we're at it, the baseline tire pressures? Everyone's favorite singing dragon hopes the answer is a definitive no. Pair Bluetooth Devices.vi PAIRS BLUETOOTH DEVICES. Say what you mean and mean what you say. By implementing functionality consistent with our language, we simplify our code and make it more SOLID.

---

Clean Language, Clean Code

As I mentioned, the automobile class example is not directly relevant to the code most of us write in our day jobs. That said, I think it adds value by breaking us out of the implementation-first mindset. As you design more abstractions, you will cultivate an ability to suspend implementation. If we can discuss our designs over a cup of coffee, we are doing something right. If we need to pull up a block diagram to show our coworker what we are talking about, we can probably do better.

This matters because mastering the language of abstraction is critical to SOLID and Agile development success. As our code becomes more abstract, it need not also become difficult to understand. Once you get used to discussing abstractions you may find yourself having stronger relationships with your coworkers, more rewarding design meetings, greater success in the industry, and better hair. If not, try showering more often.

Ethan Stern is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, NI Certified Professional Instructor, and a Certifiable LabVIEW Geek.