Sunday Serious Series: Object-oriented Programming Rebooted

Two weeks after the first post.

A lot have changed, and one of them is my understanding on OOP after finishing the first assignment (yay!), and I find my first post is basically explaining something abstract with some other abstract concepts. Which is bad, real bad. So I guess I am rewriting that part, but I will leave the first post there as a reference (to how little I knew). See my good friend http://thefabricofourpeople.blogspot.ca on why I think so XD

What is Object-oriented Programming (OOP)?

OOP is a programming paradigm (style), where the idea of treating everything as objects - from integers and Boolean (which is interestingly a sub-class of integers, will explain what that means below) to functions and exceptions, they are all objects. User-defined classes  can be created if what you exactly need is not available. As mentioned in the first post, being object-oriented can provide insights into the actual relations in between different objects, and it is very intuitive (to think about, at least) since this is often how we see things in reality. Of course, this is a kind of formality, and its implementation and support is different for different languages, so the exact details can vary.

Formality? Does that mean inefficiency?

Yes and no. When I started using OOP in the first assignment, the first step in the instruction is to 'Read and understand the Cheese class.' and all the class specifies is attribute that is an integer, and a method to compare cheese base on that integer. All the work done by this Cheese class can be done without creating a new class. The value of having an object representing cheese is not there. Instead, it allows us to think about the cheeses and not the integer. This really outweighs the cost of the additional code needed , since when I am trying to work on later parts of the assignment (solving a 4-stool variant of Tower of Hanoi recursively), I can think in terms of the pieces that I need to move, and then code with the same thing. I don't need to mentally convert it back to some specific integers when I write the code, and in larger program there may just be too much such mental work to be done and errors are creeping in. So similar to many other kind of formality, it allows us to pay a small price and avoid a lot of trouble. It should be noted that it does not magically do the work for us, nor it is capable of doing something that the language itself could not accomplish.

Okay, does OOP has any other drawbacks then?

In my opinion, yes - some small ones do exist. Creating an extra layer of formality can lead to confusion when different people do it differently. To avoid this extra documentation and communication are often necessary, which is again work to be done - this also happens in the programming language level. Another possible problem is that while the formality makes it easier to think within its framework, it sometimes affect the ability to think outside of it. I don't know how big this problem is - this is purely theoretical, but I guess awareness is needed to avoid being constrained by OOP.

I guess this should showcase OOP a bit better than the previous post XD I will be posting shortly to talk about the assignment more specifically.