Classes and objects. Programming vs philosophy

Few days back I had an interesting discussion with a colleague. We both have studied philosophy earlier in our lives so our discussion went into an interesting direction of mapping programming concepts, more specifically OOP concepts, to philosophical ideas. This discussion was very interesting to me, since when I started to learn programming I did not try to do this at all. It’s strange because it would have been probably easier to learn using analogies to familiar concepts. Most probably, I was thinking at that time that programming and philosophy are totally unrelated. The discussion with my colleague proved me wrong, so I thought about writing a short piece aimed to map classes and objects, one of the pillars of object oriented programming, to philosophical ideas.

For those who are not that familiar with classes and objects, a class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods). In other words it’s something like a blueprint that specifies certain characteristics and behavior. When you want to build a house, you first go to an architect which will draw a blue print of the house for you. Even if the blueprint contains all the characteristics of your house, it’s still not a house that you can move in. You still need to build it. And that’s where objects come in.

In the class-based object-oriented programming paradigm, object refers to a particular instance of a class, where the object can be a combination of variables, functions, and data structures. Coming back to the house example, the finished house is an object that implements members of the class, in our case the blueprint. Therefore your house would need to have also a name. In my case it would be something like “Dan’s house”. The cool think is that another friend of you could use the same blueprint (so the same class) to build it’s own house. In the end we would have then two different objects, with different names, that are an instance of the initial blueprint. Still, the first one is yours and the second one is your friends.

Sure, when  both you and your friend are building the house, you might implement some properties of the blueprint differently. Maybe you color your walls in different colors. So that’s why each object is, in my opinion, a not 100% perfect representation of the class (the initial blueprint).

From a philosophical point of view, Plato came up with the so called theory of forms or theory of ideas. Plato’s theory assumes that non-physical (but substantial) forms (or ideas) represent the most accurate reality. In other words, Plato thinks that our entire world is build in accordance to the unintelligible forms or ideas. These ideas are the perfect representation of the world that we are not able to see. Further, each object that we see in the real world represents an idea or form in a more or less accurate way. In a certain way, for Plato the objects are instances of the non-physical ideas. The resemblance to classes and objects is here obvious. Sure, this is an analogy with all the limits that derive from it. Also, the brief presentation of Plato’s theory of ideas is a huge oversimplification, but still, I think that the analogy is valid.

As it seems, programming and philosophy might not be to parallel universes, so intersections might exist. I’ll probably come back to these intersections between programming and philosophy more often on this blog. If you are also passionate both about programming and philosophy I am really curious on your take on classes and objects in programming and philosophy. So drop a comment and let’s start a discussion. Hope to hear from you real soon!

Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *