C-ing Objectively

A.K.A. “Your Brain on Objects” F.K.A “Objectifying C” B.K.A “As Easy As A PIE”

(WARNING: This is about a programming concept!)

The History (Skip if Context Bores You)

Once upon a time, people had to program procedurally. Do this, then that, jump here, go back from whence you came…It was…weird. It really, really sucked, because people wanted to do super cool things that could be really complicated without requiring more Tylenol.

C was in that procedural mold, and when it came to be all those four (and change) decades ago, it too was the Neo of the software engineering Matrix. Before it, languages like Pascal and Fortran had taken admirable cracks at hiding the ugliness of the 0’s and 1’s that lurk behind any well meaning program, but none had done so with the panache and wide reach of C.

Then Steve Jobs was born to save computing from itself.

Well, let’s not get ahead of ourselves. In 70s and 80s Dennis Ritchie and Brad Cox, took inspiration from Alan Kay’s pure OO language, Small-talk80 as they implemented object oriented principles into C. They developed a strict-superset of C that they called “C with Objects”. Poet hackers went on to nickname the new-fangled language Objective-C and it stuck. The noun form of “Objective” means Of or relating to a material object, actual existence or reality. More on than later

Ok, now back to Steve Jobs (how procedural of me). No longer a boy, Jobs was a Silicon Valley Prince in exile from the company he had built. To spite his prodigal son, he started NeXT step with the modest goal of revolutionizing the future of computing. When Jobs and his motley crew of rabid innovators set out to invent the future of operating systems they needed a new language to base it on — so they licensed Objective-C. They predicted that its implementation of object oriented principles which would allow developers to build programs more easily.

In 1996 Jobs’ exile was complete and he was where he belonged — at the core of Apple. With Jobs, came an (expensive) bonus — NeXT, complete with it’s shiny new OS and programming language. The Unix based OS was blended with Apple’s extant system and Objective-C was made the official language for developing for the platform. Naturally, iOS — which is a stripped down version of OSX — used the same language so encourage Mac developers to build for he phone.

The Principles of Object Oriented Programming (OOP)

Object Oriented Programming is the truth. It starts from the idea that everything is an object that has a physical counter part in the real world. Objects have two main parts — data and behavior. Objects are things (with characteristics) that can do stuff — to itself or other stuff.

For some reason, interviewers want to know if you’ve ever cracked open a CS book before. So they’ll ask you the textbook CS101 question:

What are the four principles of OO?

And if you’ve been programming for 2 months to 2 decades and you’d never heard that question before you might feel pretty dumb, when in fact you have certainly been implementing OO principles without really thinking about it. OO principles are general ideas that all OO languages use, albeit a bit differently.

Let’s start with an acronym: A PIE

A is for Abstraction

Abstraction is all about hiding complexity. When we abstract things, we keep things on a need to know basis. You don’t really need to know about 0’s and 1’s or even assembly, to write a desktop program. Programming languages in and of themselves provide abstraction. As Drake would say, there are levels.

Abstraction allows you to focus on what’s important while the rest is out of view. This is very necessary when you’re programming. Imagine trying to figure out how to connect with APIs, present it on a GUI, and then manipulate the data while having to worry about what the 0’s and 1’s are doing, and how the code in an API was written.

Examples of abstraction:

P is for Polymorphism

but first, you should probably understand Inheritance (farther down)

Poly = many; Morph = forms

Polymorphism refers to the ability of objects to do different things when sent the same message. For example if we send a findPerimeter to a rectangle and circle object, respectively ( [rectangle findPerimeter] and [circle findPerimeter] )— the implementations would likely be different. The rectangle would use 2*Width + 2*Length while the circle would use 2πr². Polymorphism is closely tied to inheritance. Rectangle and circle would probably descend from a shape class that has very basic properties that all shapes might have — such as perimeter, area, color, and name. Perimeter and area are likely only method declarations, with no bodies since every shape has a different formula. Objective-C employs dynamic binding which means that at run time an object will implement the appropriate version of a method based on its class. For example, in the rectangle object, it did findPerimeter in exactly the way I told it to for rectangles.


Overriding: See rectangle/circle example above

I is for Inheritance

In OO we are concerned about the relationships between objects, because it helps us find commonalities between them and reduce duplication of code. For example, if we find the cars, trucks, and motorcycles have similar characteristics we might create a vehicle class to hold those characteristics in properties.

Inheritance describes relationships where existing classes give rise to new classes. It is described as an “is a” relationship as in a car is a vehicle. The reverse is not true because not vehicles are cars.


Class inheritance w/subclassing. All classes descend from NSObject. All subclasses inherit all methods and instance variables from exactly superclass. Every time we do super.property we are taking advantage of inheritance.

Protocols allow for a form of multiple inheritance where you ascribe an implementation to a method declaration. Protocols are like a contract that lists requirements while leaving implementation up to the programmer.

Benefits: reusability (you won’t have to start of scratch overtime you make an object)
Adapt functionality by overriding the method from the superclass.

Summary: Make new shit, by reusing old shit

E is for Encapsulation

The first two definitions that google returns for encapsulation are pretty handy.

  1. enclose (something) in or as if in a capsule.
  2. express the essential features of (someone or something) succinctly.

When you’re encapsulating you’re bundling data and the operations on that data.

There’s a common data structure called a linked list. It’s kind of like an array, except the number of indexes aren’t fixed. The developer could have written X-line of codes, but I don’t need to know what variables are inside of it, what techniques he used or anything about the code at all. I don’t need to know anything about the implementation. I only need to know how I can use it for my needs. The developer only needs to allow me to create, read, add, and destroy (CRUD) entries. That makes it easier for me to use this linked list without having to worry about what’s behind it.

Encapsulation allows me to change the implementation of my class without messing things up for my users (other programmers). Someone using my linked list will probably only need to do those functions, but I might want to change the code behind those functions at some point (make ‘em faster or more robust) for example.

One of the operations on that data might getters and setters. Some conflate this with “information hiding” when that is not the intent per se.


Class bundles properties and methods.

Properties are backed by instance variables and getters and setters.

Variables are private to classes and methods unless explicitly made public. This prevents similarly named from conflicting with each other. This is related to the concept of namespace.

APIs: Once a service change how people access their API other people’s code might be broken. The service is probably changing things internally all the time while keeping the API as constant as possible.

Why it’s important:

Conceptually easier to manage.

Less overlapping variable names.

Bottom Line:

You want to be able to change shit in your code up, without messing other people’s shit (that relies on your shit) up