Object Oriented Programming (OOP)

How did it get started?

Once upon a time . . . no seriously, back in the early to middle eighteenth century, folks figured out how to program a machine that wove textiles using punch cards. In the nineteenth century, Ada Lovelace offered an algorithm-like programming process for Charles Babbage's primitive analytical engine. However, programming as we know it really came about in the early to middle twenthieth century, particularly in the 1950's and 1960's, and the rest is our recent history. As a note, the idea of using punch cards in early computers was borrowed from that early weaving machine.

As programming became widespread, programs of every kind were being created and used in society, and for the most part, they worked pretty well. However, as time progressed, the programs got larger and larger and did more and more things. These monolithic, or tightly packaged programs and systems struggled to keep up partly due to how much a program had to check for so many different possible conditions, and in many cases due to the number of bugs or problems that could find their way in to the programs. In other words, the programs did not scale, or adjust to growth very well.

During this period of massive growth in both the software and the hardware related to computing, a couple of things were happening. First, operating systems were being designed to manage programs and operating systems are usually much more complicated than most programs, and second, the idea of Object Oriented Programming was thought to be a way to handle scaling programs and systems up. This concept was proposed by Alan Kay in the mid 1960's. A couple of programming languages, Simula and SmallTalk, with a focus on messaging between parts of a program were created during that time but, other than some folks who researched and played around with them, they were not used a lot.

One component that was being used regularly however, was a record or data structure, such as the struct in the C programming language which was heavily used in the IBM operating systems and others. Use of these records was likely the first step toward the concept of an Abstract Data Type (ADT), meaning a new data component could be created with a package of data. For example, a record could represent a bank customer holding data such as name, account number and balance, address, and so on. The abstraction here is that it could be labelled and represent a Customer but actually held a variety of different, more primitive data within the record.

To continue the story, programs were getting very large and difficult to manage. The monolithic programs acted much like a single store clerk in a large grocery store handling all the stocking, bookkeeping, meat cutting, bread baking, etc., all in addition to serving customers one at a time as they came to the front counter of the store. So, in the late 1980's and into the 1990's, programmers were taking another look at the idea of Object Oriented Programming.

So what is it?

• Object Oriented Programming (OOP) is based on the natural division of labor found in most production systems. Going back to the grocery store circumstance, imagine that poor grocer trying to satisfy the needs of all the customers with all their different requests and needs. The super market is a concept that came along to lighten the load for that grocer. In a super market, or what we now just think of as a grocery store, there are folks at the front who know how to add the prices of your products up and bill you for them. Their data is the price lookup, the coupons, and the weekly sales, and their actions are the math operations, the bagging and product handling, the friendly customer interaction, and so on. However, in the back of the store is the bakery. Their data consists of recipes, ovens, mixing bowls, and so on, and their actions are the measuring, mixing, and baking of the products. Expand this thinking to the meat market, the canned goods, the produce section, and more, and you have improved things in three important ways:
  
  
  • You have better expertise in each of the store's areas that one person cannot have for a whole store; the quality is improved (and the failures -- bugs -- are reduced)
  
  
  • You have a division of labor so that bakers, meat cutters, and produce managers can handle and focus on in their own store areas
  
  
  • You can build and upgrade each individual system without bothering the store overall. You can get a better refrigeration unit for the produce folks, and bigger oven for the bakery section, and larger shelves for the canned goods area and the rest of the system (i.e., the store) is not significantly harmed or limited

The best part of all of this is that the store owner can just hire a bakery manager, or store stockers, or front end clerks, and not have to know much about any of them, other than how to manage them as a group. This is where the communication from the 1960's research comes back. All of the components in the store must be able to communicate with each other and the management to keep the store running.

OOP is built exactly this way using Classes. There can be a Customer class that can manage the data and operations a retail business would conduct with its clients. There can be a Student class that manages all the information related to a given student (e.g., name, ID number, calculating GPA, updating residence address, etc.). There are other classes that can manage very fast and effective access to varying kinds of data. All of these are available to a programmer so she can write a program using these tools and not sweat the details.

Now to note, classes are not actually used themselves. Classes are essentially templates or designs as to how the bakery or data management operation holds its data or conducts its actions. Objects are what are actually used, and are created, or instantiated from a specified class, and then used as power tools by the programmer.

A class is a record on steriods. Where the records held a variety of different data, a class holds data and it has the tools to manipulate that data. As mentioned above, a class might hold student information such as your name, student identification number, GPA, and your home address. However, it can also enter, edit, or retrieve your home address, and it can recalculate your GPA each semester and add it to your student information to later be formulated to, and displayed as a transcript (which the class can also do).

To repeat, classes are abstract data types, or ADTs. In the above case, you would just call this information "Student Data" but there is much more in the details of all the individual data parts, integer student identification numbers, String names, floating point GPAs, and so on. This is the concept of abstraction meaning that some symbol represents a much more complicated system without describing the details.

Is that it?

Nope. There is so much more to learn about classes. However, having a flavor for the history, background, and thought processes related to classes, you should be able to build your own ideas of how they work, and how they will work for you in the future. Stay tuned, and continue on to the next chapter.