In your research as a beginner coder, you will probably come across the term “object-oriented programming” to describe certain coding languages and approaches to coding. But what is object-oriented programming, and should beginners learn an object-oriented coding language? Will knowledge of object-oriented programming help you reach your goals of landing a job as a software engineer? We asked Graham Troyer-Joy, a Lead Instructor at coding bootcamp Flatiron School, to explain!
Graham Troyer-Joy is a Lead Software Engineering Instructor at Flatiron School.
Graham is an experienced software engineer, having worked for several tech companies in Chicago, and also taught at another coding bootcamp before Flatiron School.
Object orientation is a way of organizing and structuring your code. It's not in and of itself a programming language. It's a way of working within a programming language.
Object-oriented programming originated at MIT in the late 1950s, early 1960s.
Object-oriented code continues to be used today and continues to evolve. People are still talking about and arguing about what the best way to do object orientation is. Sandi Metz, one of the superstars of Ruby programming, recently released a new edition of her book "Practical Object-Oriented Design in Ruby" which gives both new and experienced developers a way to understand the best practices for object orientation and make the best choices in their code.
What makes a language object-oriented is its ability to create objects. Your code is organized into these objects, and those objects consist of pieces of data on the one hand, and behavior on the other hand. These pieces of data (there can be many of them or a few of them) are sort of like the ingredients in a recipe. The behavior is like the steps in the recipe that you go through in order to make the whole.
Example: If we've got a recipe over here for potato salad, a recipe here for coleslaw, and then another recipe over here for cornbread, your potato salad recipe can tell the cornbread when to go into the oven.
Objects can talk to each other and interact with each other. The technical term is sending messages to each other or calling methods on each other. Each one of those objects has relationships with other objects in your code while staying separate and taking care of the things that it's concerned about.
Because object orientation is not a language in and of itself, it's more of a structure, it can apply to a lot of languages or not at all.
Example: I liken it to something like a paragraph. Paragraphs can exist in a lot of different languages. They have a structure, and like objects, a good one is not too long, about one thing, and doesn't rely on information from a lot of other paragraphs in order to make sense.
The object-oriented languages I've worked with personally are:
There are many, many more. And there are many arguments about what makes a language object-oriented or not. All of the languages I listed implement some sort of class. A class is like a template for creating objects.
Example: let's say we have a Spice Girl class. All the Spice Girls have certain things in common. All Spice Girls have a name. They have a spicy name, like Scary or Ginger or Sporty, but they also have a behavior. Spice Girls can go on tour. They can zig-a-zig-ah. All Spice Girls have those things in common. Individual Spice Girl objects may have different names or adjectives, but they all behave in the same way based on the data that they have associated with them.
Some programming languages explicitly use structures that aren't related to an object. There are still arguments about what makes a language object oriented or not, but some examples of non object-oriented languages are:
I think object-oriented languages are really good at:
Processes that consist of nouns that connect via verbs
Things that interact with each other in specified ways.
At Flatiron School, we spend a lot of time talking about object relationships and how different objects relate to each other.
Code in our lives is everywhere. And a lot of that code is object-oriented. Some of it’s not. But everything from native apps, and every single iOS app out there contains at least a little bit of object-oriented code. I think the same is true for Android. Object-oriented code is everywhere, from airline avionics systems to medical devices, to web apps, to native apps. literally everywhere code is.
Some apps built with object-oriented code (specifically Ruby on Rails) include:
There are a lot of different kinds of jobs that are available to someone who knows object-oriented programming. Just as object-oriented code can be applied to a lot of problems, those problems need people to work on them. That could include:
Designing systems for avionics and airplanes
Building a point of sale system for a restaurant
Working on an online web store
Creating mobile and tablet apps.
I think the main one that springs to mind is functional programming. Whereas object-oriented programming divides things up into objects with methods, behavior, and data, functional programming tends to chain together using functions – structures that are actions with an input and an output. Multiple actions, each taking the output of the other, lead into a process. You can think of it as a pipe that's been welded together with a lot of different processes in it. That's the basis of functional programming.
I don't think there's any wrong way to learn how to code. I think object-oriented code is a good starting place for many beginners because it is somewhat concrete. Objects and methods correspond to nouns and verbs that we might see in the world around us.
As you develop as a programmer, you get more and more comfortable with abstractions – pure ideas that are put forth in code. Those are hard to dive into initially, and object orientation gives you a nice way to build up to those. With that said, they're not a requirement. We teach object orientation here in Flatiron School’s Software Engineering Course, but there is no wrong way.
One of the cool things about teaching students object-oriented programming is that we're introducing not just object-oriented programming as a specific thing, but a whole category of design patterns. It's a simple introduction to the whole concept that there are a lot of different ways to write code, and some of them are better than others. Better in the sense that they will make your life easier in the future and your coworkers' lives easier, and you will not paint yourself into a corner as much as you might have otherwise.
How to debug – what to do when your program is broken, diagnose and find the problem, and then fix it.
How to engineer a big app that has a lot of small pieces that work, but also work well together.
How to work together with other people – writing software is never an individual sport; to be effective developers, students need to learn how to collaborate.
If you're learning how to code, the most important thing is to just dive in. Start somewhere. I think Ruby is a great start. If you don't like Ruby, try something else.
The other really important thing is to find a community that can support you, give you feedback, and give you other people to talk about code with. Helping other people is a great way to learn how to code and solidify what you've already experienced. Flatiron School has evening events at every campus, where you can get an introduction to code with other beginners.
How Laura Launched Her Creative Tech Career After BrainStation
Why Rena chose Berkeley UX/UI Boot Camp!
Data Engineering vs. Data Science vs. Machine Learning Engineering – what's the best career for you?