Object oriented programming expresses the design in terms of the problem domain rather than the programming domain.
There is need for a new software application that obtains configuration information from Automatic Test Equipment (ATE). Thinking about what needs to be accomplished, my first thought would be that a cluster of configuration information would be common to most of the program. So I might write something like this:
Hmm, we have several nested cases. If we printed out the block diagram it would look like this:
Let’s try an object oriented approach to the same application. The first thing we would do is figure out what objects we would need. If we made a top level object, our top level VI might look like this.
The VI is simpler. There are no hidden cases. If we print the block diagram, the above is what we get. Each function is obvious from the icon on each VI. But perhaps most significantly, the conditions that affect the program are now obvious. All the logic depends on two conditions, whether a configuration file already exists and whether the ATE configuration changed. These now stand out in our top level VI.
