Object-Oriented Programming Basics

I am okay at python. I can use all the packages I know and quickly learn any that I do not. I have heard object-oriented programming (OOP) in the background a lot but it was not till recently that I took the time to fully understand why it is such an important development that forms the backbone of not only python but many other of the most popular languages.

What is coding like without OOP?

To fully understand OOP, I think it’s important to understand what the alternatives are. If you are only well versed in Python, like me, you might think that certain ways python works are ways that all languages work, just with different syntax. Different dialects may have a completely different vocabulary and pronunciations but similar sentence structure, like the Germanic languages, and then some languages, like Chinese may have a completely different structure and vocabulary. They are all intended to do the same thing, they just go about it in varied ways and some vary more than others, to the point where the concepts inherent in one language may not be applicable to another at all.

There are an array of non-object-oriented programming paradigms. Let’s look at a couple that do things the most differently.

Declarative programming tells a computer what to do and the logic that should guide it but does not define the control flow. This is like SQL, where you give a query, narrow it down with logical statements but depend on the computer algorithm to actually fetch the data.

Functional programming is completely tailored for executing mathematical functions. OOP has functions too but is not designed specifically to use their logic in an efficient manner. A Swedish language called Erlang was developed in the 1980s and is what a lot of communication applications like WhatsApp are programmed on. Rather than be defined in terms of objects, Erlang is defined in terms of processes.

So what defines OOP?

Well, objects silly! More specifically OOP languages define objects, classify them as types and have methods or procedures tied to specific objects. In python when you set a variable equal to “a string”, the language now knows that it is a string and the methods that can be applied to, how it can be modified or stored, all without ever telling you.

The Interview Question

If anyone actually reads this blog, this is probably the part of that you have been hoping I would get to The Four Pillars of Object-Oriented Programming. The reason I wasted all your time with some background information was because there are a million blogs about this, and none of them clicked for me until I did more research into the competing paradigms of programming. The best blogs are ones where you feel that the author has a similar, explicitly detailed mindset to yours, so I figure I would try and make one that followed my mindset, rather than just rephrase the same generic descriptions of these four aspects of OOP.

Abstraction

So in Python, imagine you have a string and you call string.title(), the .title is NOT the code that capitalizes the first letter, it is calling the predefined method that goes through and capitalizes the first letter of each word’s logic which you never see. Abstraction methods or algorithms can be called in an abstract way without the programmer seeing or interacting with any of the code. This methodology is primarily for making code easier to read and problems easier to grasp. If you know what the abstracted methods are doing you can easily read through much less code. Even if you do not, well-written function or method names will be self-explanatory, making it easier for beginners to see what is going on as well. It might make you feel like Neo to have a wall of text facing you, but object-oriented programming aims to avoid this by abstracting actions into simple verb terms.

Encapsulation

A good metaphor I heard to describe encapsulation is creating a frosting recipe and linking to it in a cake recipe, instead of just adding all the text of the cake recipe to the same page. Now if you have another recipe that requires frosting you can link to that encapsulated recipe again. By keeping code in encapsulated bunches it can be easily tied to other code and is better organized. This one goes hand in hand with abstraction; it relies on a similar way of keeping code tightly organized and legible. You cannot abstract something that is not encapsulated, your reference needs to be tightly defined. A common python example I have come across is referencing one of my own functions in another custom function. Since the functions are encapsulated, they can easily be called even in the background of another function.

Inheritance

Inheritance is the idea in object-oriented programming that there can be parent and child classes. A child class will retain all the attributes of the parent class but maybe include some new changes. This is the process by which you can use functions within another function. When it is called, it automatically inherits all the attributes of the other function.

Polymorphism

In programming, polymorphism means that we can have the same function be used for different types of objects. An extremely simple example of this would be how the plus operator will concatenate a string or add numbers. It recognizes the two different classes and does different things for them. Len() can return the length of a list or the number of elements in a string! I always took it for granted that python had intuitive functions or operators that could work on multiple data types, but this is an intentional programming choice to make it more intuitive.

Criticisms of OOP

The main criticisms of OOP come from it being geared toward usability and not efficiency. There is a lot more complexity involved in doing all this compartmentalization than just running other languages. On the other hand, OOP can be more legible and theoretically save expensive developer time. There are also aspects of OOP that can be bad at handling time data.