DISCLAIMER: This is the talkie-talk of a new-ish programmer. Leave me be. This piece is mostly for my benefit, as an exercise in understanding through explaining to someone else. If I misrepresent something, feel free to correct me. I can be reached at chris@lonelylion.com.
The first program I ever wrote looked something like this:
10 print “Chris is cool!”
20 goto 10
It’s a linear program, it says, “print ‘Chris is cool!’ on the screen, then do it again and again and again, to infinity.” Up until a decade (or so) ago, this was the type of programming that ran the globe. Programs were executed from top to bottom.
In high school, I took a C++ class. C, the predecessor to C+, works like the program above. It executes commands from top to bottom. C+ is Object Oriented. At the time, I didn’t understand why this was a good thing. My teacher smelled like bologna, and I was pretty convinced I wanted to be a lawyer. I didn’t pay attention like I should have. Now, nearly ten years later, I’m starting to understand why she’d get all giddy about OOP (Object Oriented Programming).
A program is made up of instructions and variables the instructions act upon. In linear programming, every variable is unique. Even though there may be a relationship between two variables, it’s up to the programmer to understand and respect that relationship.
As an example, let’s pretend the program is a car. Every piece of the car is a variable. Gas needs to move through each of these pieces. Although we know what’s going on, the car doesn’t. The car doesn’t understand the relationships between its parts. The relationships exist, but it’s up to us to acknowledge them.
In Platonic thinking, there is an abstract car. The abstract car is kind of like a definition. It’s a “class”. There are different cars in the world, they have different parts, but they’re all “cars”. In linear programming, there can only be one car. It is what it is. There are no variations. If you have two similar programs, there’s no way to say, “they’re both different types of cars.”
That’s where OOP makes the big jump. OOP takes Plato’s idea, it says, “these variables and instructions are an abstract definition of THIS.” THIS is known as a class. A specific this is known as an object. One more time, the class is the definition, the object is the actual thing.
As a non-car example, let’s take a circle. A circle, in our thinking, is defined as a radius, and a color. The methods (actions) associated with that circle are draw, which draws the circle on the screen, move, which animates the circle, grow, which increases the circle’s radius by 10x, and shrink, which decreases the circles radius by 10x.
Below are two fancy graphical representations of two seperate instances based on our definition. They are each objects, defined by the class circle (click on them to make them larger):


In any given programming language, to draw a circle may take 100 lines of code. In OOP, we take those hundred lines of code, make them more generic, call it a class, and define the variables and methods of that class. Now, it may only take two or three lines of code to draw that circle.
OOP acts as an abstraction layer between what a programmer wants, and the potentially extensive code the program needs to bring that want to life. Abstractions are what make life possible. In language, we all know what the word “blue” means. If we had to describe blue every time we wanted to convey blue, we’d be pretty well screwed. OOP allows programmers to describe “blue” once, then say it as many times as they need to.
So why is this a big deal to me all of a sudden? I’ve been working on the Improv Olympic web page (http://www.improvolympic.com) for a while now, trying to design a database for all the shows the theater produces. I originally was trying to do the programming linearly, because it’s what I’m comfortable with. For some reason, I couldn’t get started.
When I read about OOP, it made sense for the Improv Olympic project. Each show has similar elements, a name, a cast, dates, times, costs. There is an abstract definition of what a “show” is, there are individual shows. I started to lay out what defined a show. After I did that, I defined what kinds of things would act on a show. I needed to put the information in a database, pull the information from a database. I needed to add cast members, I needed to present all this on a nicely formatted page. This collection of variables (name, cast…) and instructions (called “methods” in the OOP world), make up the class: show.
It was a big revelation. It’s made the job a lot more interesting. The jump from linear to OOP programming feels like a huge leap. It’s abstract thinking applied to a rigid model.