Object Oriented Programming: A Complete Guide
First things first, before we get in too deep, I want to take a moment to explain what you can expect from this article. The goal is to provide a basic understanding of what Object Oriented Programming (OOP) is, where the need for OOP languages originally stemmed from, and why this style of coding is so prevalent.
If programming is not your thing, and you are here due to an accidental miss-click while trying to make your way to the latest Taylor Swift music video, then consider this fate telling you to learn something new today. I am going to take you through such a high-level view of this programming concept that even if you aren’t much of a programmer, you’ll be able to extract a nugget or two of knowledge before continuing on to whatever shenanigans you were up to in the first place.
What is OOP?
Scholars maintain that the translation was lost hundreds of years ago. Wait, no that’s something else. It is actually an acronym for Object-Oriented Programming and all of the largest, most popular sites in the world—think Google, Yahoo, Facebook, YouTube and Twitter—are powered by them. OOP is a style of coding that allows you to group relevant code into a structure known as a class that acts as a template for future uses of the code. This allows for strict control of default behavior, how data is allowed to be interacted with and how it can interact with other parts of your code.
OK Bozo, Why Should I Care?
No matter who you are, or what role you serve, efficiency is a highly sought after attribute. Being able to maintain a certain quality of work in a short period of time establishes value. After all, coding takes time, and time is money.
In the programming world, you are often faced with a lot of the same challenges as you work on project to project. When you break things down to the manipulation and handling of data, you’ll likely begin to see similarities in the solutions you’ve used. OOP languages focus on these similarities and allow you to capitalize on that fact by delivering mechanisms you can use to organize, compartmentalize, and easily reuse your code securely and safely.
Classes are programming structures that can, when built correctly, produce templated, uniform objects. Classes give you a very high-level of control and predictability when you deal with those objects. You can decide what defaults you want the object created with, strictly define the getters and setters (functions that deal with acquiring or setting values related to the class), and any other functions that you need to exist during the lifecycle of the object.
As I see it, this is the natural progression of how code gets written:
- You write some code to do things
- Then you group that code into functions to compartmentalize and reuse easily
- You then group related functions into a shared class for the advantages I described above
- You benefit from the power of OOP characteristics and patterns
It’s getting DRY in here!
The DRY I’m referring to is the acronym for the old programming mantra, “Don’t repeat yourself.” The idea behind it is to strive for concise, efficient code where the code you write doesn’t get duplicated elsewhere. When future updates or code refactoring inevitably happens to your codebase, you only want to make the update to one location and have it ripple throughout the entire application. In a procedural programming approach, you don’t have the mechanisms in place to enforce best practices like this, and the result is messy code that is difficult to implement and maintain.
The office drawer comparison, as illustrated above, is a favorite of mine. It shows that both methods technically “work,” all the important pieces are there where you need them, but the weaknesses of the procedural approach become obvious real quick. In the procedural example, when you actually want to find something you have to dig around haphazardly trying to remember where it might be buried. It also illustrates how difficult it would be to accurately audit your drawer’s contents, an unenviable task by any measure. Our object-oriented drawer however, has relevant pieces grouped together into their own containers making it easy to find what you want, when you want it.
Design patterns to the rescue!
In the programming world, design patterns describe a regularly occurring problem and provide a universal solution to the root of the problem. In short, they are essentially reliable solutions to common problems. This can change your whole outlook on how you tackle projects because instead of approaching and viewing each task as unique, you can identify the underlying challenge at hand and apply a pattern proved to overcome it.
In general, design patterns have four essential elements:
- Pattern name: a term for us to use in reference to the solution
- Problem: this describes when you should use this pattern
- Solution: this describes what is needed and how you should execute this pattern
- Consequences: any pitfalls, limitations or weaknesses that this solution may bring along with it. This is critical when evaluating if this pattern is applicable to your task at hand.
To learn more about design patterns, I suggest Design Patterns by the Gang of Four. It’s an older book and is a tad dry… ok it’s incredibly dry. But if you push through it, I promise you will learn a ton.
If you’re a programmer, then chances are you’ve been doing a little of this already. You probably have a collection of code snippets that you have written over time that you evolve and reuse from project to project. Using OOP practices and design patterns, you can take this practice to the next level and create some really powerful stuff.