Hey! Welcome to Day 16 of 100 Days of Code. Now
today,
we're going to be pulling out the big guns, we're going to be learning about
Object Oriented Programming otherwise known as OOP.
Why are we learning about it? Well, if you think back to yesterday's project,
some of you I'm sure at some point during the project, would have had this
feeling of what on earth is going on with my code?
And the reason is because our code is getting more complex,
it's trying to do a lot of things,
and it's trying to manage a whole bunch of relationships.
So one function is changing a variable,
and then that same function is doing something else to another variable.
And at some point, the logic of our code starts looking very, very spaghetti-
like.
And it's at this point where it's really hard to track and remember what's
actually going on in our code.
So this style of programming is called Procedural
Programming where we set up procedures or functions that do particular things.
And then one procedure leads to another procedure, and all in all, the computer's
mostly working from top to bottom and then jumping out into a function as
needed.
Procedural programming is one of the earliest paradigms of Programming.
In fact, back in the days when we had older languages like Fortran and COBOL,
they rely pretty much exclusively on procedural
programming like what we've been doing.
But the increase in complexity,
the increase in the number of relationships that we need to remember and manage
starts making it look a bit like the dating history of the Kardashians.
And it gets very,
very confusing because everybody has been in touch with somebody else. Now,
the kind of relationships I prefer are one to one, me and my couch.
So how can we maintain a simple relationship in our code while being able to
write more and more complex projects? Well,
this is where the Object-Oriented paradigm comes in really handy.
Now let's imagine that you're tasked with creating the program for a self-
driving car. Now, as you can imagine,
this is a pretty complex project and it's many,
many notches above the coffee machine that we've been struggling with so far.
But what if you broke it down? What is a self-driving car?
What are the different components that make up a self-driving car? Well,
it probably needs some sort of camera module to keep track of what's on the road
and to recognize what's on the road,
it will probably need a form of lane detection to know if we're actually within
the lane or if we need to turn off or if we need to park, and it will need some
way of navigating so that when the user says, I want to go to the bank,
they identify the branch they want to go to,
and then the navigation gets set up and the car knows how to get there.
And finally, you'll probably need some form of fuel management, right?
What should happen when the fuel gets low?
Should it go and automatically recharge at a specified point?
Now I'm obviously simplifying this task. There's a lot,
a lot more that goes into making an automated car.
But we've already managed to break it down into several modules that we can
think about tackling, right?
But imagine if you have a whole team who are all working on this project and
within that team,
there's sub-teams who are working on each of these different modules.
Well then by splitting up this big complex task into separate modules,
then we can all work on this car simultaneously,
massively improving our productivity,
making it much quicker to eventually build all the software for this car.
Plus on top of that, a lot of these modules are reusable.
So if it just so happens that the next year we're tasked with building a drone,
well, a lot of those programming modules that we built, like the camera module,
the fuel management, the navigation,
that's all going to be incredibly useful in our drone delivery software as well.
And because we've taken out these individual chunks of code and modularized them
using Object Oriented Programming,
we won't have to code them up again in the same way that we might need to
if we were using procedural programming.
So what exactly is all Object Oriented Programming? We've seen that we can split
a larger task into that smaller pieces.
And each of those pieces can be worked on by separate teams, separate people,
and also each of those pieces become reusable if we need the same
functionality in the future. But Object Oriented
Programming actually takes that concept even further.
And I think the best way to explain it
is to imagine that you are tasked with running a restaurant.
So you take over this restaurant from your long lost uncle
and you realize that it's actually really hard running a restaurant.
So, first off, you have to be the receptionist and you reserve seats for your
restaurant visitor's and then when they order something,
you have to be the waitress and bring them their order.
And then of course the order needs to be cooked up, right?
So you're also gonna run into the kitchen and be the chef, create the thing that
they ordered and finally,
you're also going to be the cleaner tidying up after everybody
once they've left. As you can imagine,
if you were one person having to do all of these tasks,
that's going to be a pretty rough day. There are in fact one-man restaurants,
and I've seen some work really in well Japan,
where you have one person who's taking the order,
who's making the food, who's tidying up after you.
But the limitation here though, is that look at how many seats he has.
You can't have a large restaurant running everything by yourself. In the same
way we can't create a very complex and really large software project
if we are using a procedural style of programming where we're sort of running a
one man band. It gets very,
very complex and very hard to manage very quickly.
So lets consider the alternative.
What if we had just hired a bunch of people where they each have their own
individual roles. They're trained for it, they know what to do.
The waiter knows how to wait and the chef knows how to cook. Well,
in this case,
you could just be the manager and you can manage all of your staff and tell them
what it is that they need to do.
But then you won't have to worry about the nitty-gritty details of exactly how
they need to go about doing their jobs. So for example,
you don't need to tell the waiter
how to wait on customers and you don't need to tell the chef how to cook an egg
because they already know how to do that.
And we can use the same concept to simplify the relationships in our code and
make it scalable for a larger and more complex project.