Issue 3: Object-Oriented Programming

Hello and welcome to Confabulating a String of Contrivances 148! (C.S.C. 148) This is the place where I discuss about various topics my Professor asks us to talk about. Come to think of it, I never wrote a blog before. In fact, I hardly read blogs except to gain information about obscure topics that most people don't care to know about; in that case, whether you are my T.A., my Professor, my classmate, my friend, future me, or none of the above, I hope that you find something useful among these bytes of words!

Object-Oriented Programming is not particularly a difficult concept in today's time. Many schools and universities teach it, while many others still insist on alternative methods of programming. I don't find it a challenging concept given my previous experience with the traditional style of Procedural Programming. I can liken the two in the sense that instead of creating many variables to represent one item (object), I can now create a single object that stores many variables.

I find that the hardest part of Object-Oriented Programming is not the logic, but rather the design. The problem here is that Object-Oriented Programming requires a different method of thinking. Intuitively, we first think about "what will my program do?" Yet with Object-Oriented Programming, we must instead think about "with what will my program work with?" (This is why we practiced high-lighting keywords in class.)

Procedural Programming

Let's say we're designing a simple two player soccer game. Intuitively, we will begin by considering how two players must kick the ball into the opposing net. This thinking will entice us to begin by coding controls for two player's movement separately. After doing so, we would intuitively move on to defining the coordinates of the ball, and a set of procedures in the form of while loops that governs how the ball move, how the ball interact and the condition for victory. By the time this is over, we would end up with a Procedural style Programming. The set of instructions would be easy enough to translate into a self-help manual, but it would not be a form of Object-Oriented Programming

Object-Oriented Programming

If we are designing the same ball game with Object-Oriented thinking, we must instead consider what the game will have. We must recognize the presence of a ball, the presence of two players, and the presence of two nets. It is then necessary for us to decide what we need to know about the ball, the players, and the net. Finally, we can consider what the ball, player, and net will do by themselves, and how they can interact with each other. The problem here is that designing an Object-Oriented program takes much longer. However, Object-Oriented programs can save a lot of frustration when we start to add new features to our program - such as playing soccer with two balls for instance. 

Being that I have mostly taught myself to program for the past few years, I have become more accustomed to the Procedural style of programming. I don't believe that Procedural style is "wrong". In fact, it works fine in many cases, and can be a huge time saver for small programs. I am however, very interested in using the Object-Oriented method more often - which I am sure we will get to do more often in 148 than 108 - as it offers much cleaner code and can potentially save a lot of time when repeating objects.