evanmeagher

The phrase “object-oriented” is thrown around a lot. It’s a very interesting concept and paradigm, but it can be a hard one for non-programmers to understand.

Imagine that you want to write a recipe for making peanut butter and jelly sandwiches. Imagine that the person you’re writing the recipe for has no idea what a peanut butter and jelly sandwich is, so you have to write explicitly what to do, step by step.

The resulting recipe would be very long and contain a lot of seemingly-trivial tasks that any idiot should take for granted like “find a jar in cupboard labeled ‘Crunchy Peanut Butter’” and “transfer a glob of peanut butter from the jar onto bread using a butter knife.”

To relate this example to programming, the person you’re writing the recipe for is a computer (compiler), the sandwich is a program, and the recipe itself is an algorithm. All a program is is a set of directions telling a computer what to do, step by step.

So, back to object-oriented programming… imagine now that you’re writing the same recipe for a person who knows a bit about the culinary arts. You won’t have to explicitly tell them every step. You’re recipe will be much shorter:

1. Get 2 pieces of bread, 1 jar of peanut butter, and 1 jar of raspberry jam
2. Spread peanut butter and jelly onto corresponding slices of bread.
3. Put two slices together.
4. Eat! (optional)

This is object-oriented recipe-making. You assume that the person knows what they’re doing and thus you can give higher-level instructions. In object-oriented programming, the program that you write takes advantage of already-written packages of code (called object classes), and allows you to tell the computer what to do without having to go into the nitty gritty details of every complex task.

In the sandwich example, the more complex steps of the second recipe can be abstracted as objects to be used in the sandwich-making algorithm.

Who said algorithms can’t be tasty?