All right, so now it's time for us to start a very big topic, which is object oriented programming.
This is a programming style that you will most likely use most of the time in your career or whatever
you might do when you're trying to make your own applications or anything like that.
Object oriented programming is kind of the common style of programming these days.
We have been doing procedural programming until now.
And that's kind of just using functions and loops and all that stuff, and we're still going to use
that.
But we're going to add some kind of new structure and some new things into the mix and there's object
going programming.
So let's go ahead and get into it.
Some have to use a decent amount of analogies to correctly explain object or initial programming.
I think that's the easiest way to explain the use for it.
So a common analogy for object oriented programming, also known as OLP, is the relationship between
cars and drivers.
So that's what I'm going to use.
There's a lot of analogies you can use, but this is just one of many.
So think about when you enter a car, you have things like a gear shift, a gas pedal, a brake pedal
steering wheel ignition.
This is all part of the interface for you to operate the vehicle.
So like when you press the gas, the car moves right.
You don't really have to think about exactly how it's moving from the pedal being pressed to the car.
Actually, going forward, you just concern yourself with wanting it to move and pressing the pedal.
That's all you have to do, right?
So the engineers of that car, the one that is the ones that had to design the system that moves the
vehicle and you press the gas pedal, right?
We got some fuel being injected, a bunch of stuff going on in the engine and all of that.
So when you bought the car, you just expect it to work with this simple interface, right?
What was the reason why you bought the car?
Well, you needed to get from A to B.
You probably wanted a nice car.
You wanted to fit people and whatever.
But the main purpose is to get places right.
That's why you buy a car because you need to get places fast.
So you needn't really concern yourself with the blueprints and internals of the car and how it was designed.
But as engineers, we now need to concern ourselves with the design of these objects.
If we're engineering the car, we need to now consider the design and the blueprint.
So how does this relate to software, though?
Well, we can still continue on with the car analogy and think about it kind of in a digital sense.
So what makes up a car?
If we were to design a software version of it, what data would be associated with that car and what
actions would be performed?
So you can use what you know so far about strikes, because that's kind of a way of collecting data,
right?
We had an abstract data type with our strikes.
That was when that's kind of how we introduce structure, right?
It was for us to be able to create an abstract data type.
And we had some variables inside of it, right?
So let's think about just what a car struct would look like as an abstract data type.
So here we have struct cars, so here are some things we can have in it, you know, it's not limited
to this, of course, but I'm just for simplicity's sake, only putting a few things in here.
We have like fuel could be a float type, right?
We can have a paint color, which is a string like the car, blue or red or something.
And then the model of the car is a string.
And then the odometer could also be an integer, you know, because how many miles are in the car,
kilometers or whatever you prefer?
So this is all data, right, like these are just kind of static data members here of this car struct,
but we don't really have any actions, right?
We don't have any functions.
So what about the actions?
So let's think about some functions that might relate to this car, some action.
So here are our members here.
It went ahead and renamed Paint Color.
I'm not sure why I used this syntax in the last one.
It should be kind of camel case like this right here.
So, yeah, anyways, let's think about the functions that could exist for this.
So let's see.
Maybe like a void drive car.
So you get a certain number of miles pass to it.
And what would we have to do in that drive car?
Well, maybe we would modify the odometer, right?
Because if you drive the car and the function gets passed a certain amount of miles, you now know that
the odometer should have those extra miles on it, right?
What else?
Well, it uses feel and you drive the car, so you might need to also subtract from your total fuel
a little bit, right?
That's a set paint.
That could be a function, right, maybe you want to repaint your car or something, so you know, here's
a color being passed to it, the paint color, and you could set this paint color data member variable
here.
Right?
Then we have this returns, an integer says get odometer, so that's just getting this data member for
us.
And you might be wondering, well, why would we need a function to get the odometer?
It's right here.
We could just use it.
So this is something that we're going to talk to talk about in this slideshow.
So there is a reason to make a function that gets this rather than just use the data and access it straight
up.
So that is something about hiding data from the user, and that's something we're going to talk about
in a moment.
So this returns a flow assist, jet fuel is just like odometer, it really just gets this variable and
returned to.
And then we also have add fuel, this is Floyd, so what it's really doing is just modifying this feel
right.
You get some gallons and you're going to add some gallons to the fuel.
So those could be some potential things, of course, there could be a less that could be more.
But you know, this is one of the kind of a potential kind of configuration of data and functions that
you could have here.
So what we're going to be talking about now is something similar to strikes, but they're actually called
classes, and it's kind of going to be a kind of bigger, more robust and slightly more complex version
of a strict.
So classes really are the blueprints for something we call an object, and we're talking about this
object oriented programming, you know, and car.
We have the idea of a car being an object in code, and the class is the berl blueprint of that object,
the blueprint of the car.
So they describe the object and they provide functionality to interact with that object and its data.
So down here I have a box, this is kind of UML style ish diagram right here.
We have the class name would be car involved here.
These items right here would be data members.
So these are the member variables, the member data variables.
And then down here we have the functions which we refer to as member functions.
We call them member because they are members of this car class.
So these are the data members or member variables.
These are the member functions.
So this is the functionality of the car class.
So here we have all of those functions that we listed.
So the syntax for creating classes is pretty close to structs, so we notice instead of struct, we
just put class and then has the same brackets here.
Also note that we have a semicolon coming after the close bracket here or brace?
Curly brace.
And then we have a combination of variables and functions in here.
So all of our information is contained inside here, so here's the member variables.
Here are the member functions.
So an important thing, though, that is very useful in classes is something called access specifies.
So think back to the car, right and the driver.
So remember how we want certain things to be available for the driver, for the interface of the car,
but maybe not others, right?
Like, what if we don't want the user or the driver to be able to modify the original odometer, right?
We want the car to drive.
And we want like Miles, to be added on to the odometer and we want the odometer to be able to be displayed
to the driver.
We want the driver to be able to see the odometer.
I know the kind of you're being technical about it.
Yes, there's like a trip odometer that you might do when you reset the trip odometer just to see how
many miles you've gone.
But we're talking about the overall odometer of the car, right?
How many miles are in the car?
So of course, if you kind of scammy and you're selling your car and you're trying to, like, take
off some miles or something, then that could be possible.
But we don't really want users to do that right.
We want them to only be able to see the odometer.
We don't want them to be able to change the odometer.
The odometer is a member variable, right?
Here we have a get odometer that simply would show the user how many miles are on the odometer, right?
It's an integer.
So this just returns the miles of the odometer to the user, but it doesn't let them modify the odometer.
And why is that?
Well, because the user, if we're thinking about this software version of a car, the user might call
this function.
Because they want to get the odometer, but when they call this function, it's up to us to put the
code that runs inside this function, right?
So we can pull whatever code we want here.
We don't have to modify the odometer and we don't really want to.
We just wanted to give back the number that's stored inside the unarmored array, right?
And that makes it so the user isn't changing our odometer variable.
All they're doing is accessing what the value is stored inside of that, right?
The integer that's stored inside a diameter.
So since we have that function, you know, when the users use these funds that function and maybe when
they use drive car function, we can make our own modifications to odometer right.
When we use to drive car function, we can add miles to it.
But we don't want them to have direct access to this variable to do whatever they want at any point
in time, right?
So this is an important concept and it's something that we call encapsulation.
And we use something called access pacifiers to do just that, we specify the access level, right?
The engineer, ourselves, being engineers, we have the ability to access these variables here, right?
Because we want to change them like Odometer, but we don't want a user to be able to directly change
it.
And so we're not we're going to revoke their access to change it, right?
So what we do to be able to put this in code is have these access specifies here, so we have something
called public and private.
So here these are public member functions now.
So these are available to the user if you want to think about the analogy.
These are available to the driver.
So we want the user to be able to call these functions.
As you'll see in the near future, we're going to make car objects, this is a blueprint, and what
we're going to do is make lake car one car to car three as objects in the user code right.
We're going to pretend that we're a user and we want access to all these functions.
But as the user, we shouldn't have access to these necessarily.
It's common practice in programming to make the member variables be private.
And that is because we kind of have this idea of making an additional layer of security by having the
functions only be able to be accessed through a function.
And what that enables us to do is decide what the user is allowed to do with the variables.
In this case, the users are only allowed to get the odometer if they want to see it or if the user
drives the car, we modify the odometer and the fuel in the way that we want to modify it.
We're not going to let the user choose how many miles get taken off the odometer when they drive the
car or how much fuel gets used up when they drive the car.
That is something that we've designed, right?
We are the ones that say how much fuel gets used when the user is driving the car a certain amount of
miles.
Same thing with the odometer.
That is the point in separating out stuff into public and private.
Private means the users cannot access these public means the user can access these.
All right.
Think about another chunk of code where we are trying to access stuff from this car class.
This stuff here will be accessible from this other chunk of code.
This stuff here will not be accessible from that other chunk of code.
All right.
So another thing that you might notice is that these are only function prototypes.
So think back to when we were making some functions and putting them above main versus the low main
and stuff like that.
When we put stuff below main, remember, we had to use some function prototypes here just to be able
to access those so Maine can know that they existed, right?
Because it was kind of in that specific order where, you know, Maine didn't know how to call a function
if it hadn't been previously implemented.
So what we had to do was define the function prototypes just so they were available for use right now.
And that's what we're doing, too.
We're putting prototypes in here.
Not to say that you can't put the implementation here instead of just the prototype.
But what we're going to be doing as we move forward is we're going to be keeping our prototypes here
and we are going to put our implementations outside of the brackets of this class.
That's what we're going to be doing.
We might be putting some stuff in here sometimes, but what we're going to do most of the time is after
this bracket close bracket semicolon, this is where we are going to put implementations or as you'll
see in the future, we're going to put our implementations for these functions where the actual code
goes in the car, sometimes in a completely separate file altogether.
So that is something that we'll be doing in the future.
But just know right now notice that we're only using the prototypes here, only defining the prototypes
in this public public section.
So what would a function implementation look like for this, though?
So let's say we put some code down here after this closed bracket semicolon, what does get odometer
look like?
This is the prototype right here, right?
But what would the implementation of this function look like?
Well, it looks like this, and you're probably like, Oh yeah, this is.
It makes sense.
You know, we got the brackets here, we got the parentheses.
It's doing some stuff.
It's returning, though.
But wait, what is this?
Why is that there?
Where have we seen this before?
Well.
This is something actually called the scope resolution operator, and we've seen it used before whenever
we're not using the namespace STD.
Right, we had to use this scope resolution operator.
So the scope resolution operator is something that can tie a namespace to a variable like type like
this.
It can also be used to tie a class type to a function name here.
So in this case, what we're doing is we're saying get odometer is part of the car class because you're
like, well, get odometer, where's that coming from?
What if we had multiple classes and stuff?
We're like, OK, well, this get odometer function right now.
I just want to let you know that is part of the car class.
So this is part of the function name.
The full function name is car class scope resolution get odometer so you can think of all this being
the specific function name.
Also notice something important is that we put the data type, it returns before the function name.
That's something we've done before too, right?
So we've put the integer return type of the function before get odometer.
Now we're even though we're adding car call and call and get odometer.
We wouldn't put integer after a car call and call in or something like that.
We would always put the return type of this function.
As the first thing, and then we put car Coleman call and get odometer, which is all part of the name.
So just want to make that clear.
It's an integer return type because it's returning the odometer.
And what is the odometer type, well, integer, right?
So that's why we have an integer.
So let's look at the rest of the function implementations for this class.
Another thing that I noticed is there is a small mistake here.
This should have a stage colon colon here.
You notice that these have colon colon before the string.
So it's kind of implied that I am not using the standard namespace up here.
So I probably should have a steady cold colon right here in this function prototype as well.
I noticed that I put it right here, but just wanted to point that out.
I noticed a little error.
So this is what all of the function implementations for this class would look like.
So here's all the prototypes, right?
And here's all of their implementations that you could potentially put after the class here past this
curly brace with the semicolon.
So let's take a look at some of these.
What is the same?
What is the similarity between all of these?
Well, they have the car, Colin Colin in front of them, just like we noticed before, right here in
front of get odometer.
It's not just get odometer that has car Colin Colin in front of it.
It is all of the member functions here in this class.
We need to put this car call and call in for the C++ compiler to understand that it is attached to this
class.
So when we do this, implementation knows that this drive car function is coming from the car class.
So this drive car function, you notice that what we do is we add some stuff to the odometer, add some
miles that get passed to it, right?
So now there's more miles on the odometer.
We also subtract some fuel where I just have this really basic formula where it's just miles over twenty
two.
So that is what we're going to subtract from the fuel if we're just thinking about gallons.
Or, you know, whatever you're using leaders or something like that.
So here, you know, set paint, we set the paint color.
These are just returning the odometer and returning the fuel.
So this is something to do with that accessibility, right?
And the encapsulation idea, which is where we don't want the user to be able to directly modify the
variables.
So what we've done is we made these functions that are access or functions where you can access the
variables, right?
So the user wants to know what's the odometer?
Well, the user doesn't have access to the variable here.
So what should we do?
We should make a function here.
That's public.
That is called get and then whatever the variable name is, right, get odometer.
So that returns the value of the odometer.
And we have the same thing for fuel.
What if the user wants to know how much gas they have left in the tank?
Well, that's a very normal thing, right?
You want to know if you're about to run out of gas.
So the user could call this get fuel function on the car object and they would get the fuel.
And this is another access or function.
We're enabling the user to have public access to the value still inside here, but we're not letting
them modify the fuel directly, right.
That is up to us right here.
The user is allowed to drive the car, but we choose how the fuel gets modified right.
Right here you see that also, when the user adds fuel, of course, we need to let them put more fuel
in the tank at the gas station, right?
So we have this and gallons that they can pass to an add fuel function and that adds fuel function modifies
our car class.
How does it modify it?
Well, it adds the gallons that the user passes to this function to our fuel member variable, right?
This is private.
The user doesn't have direct access to the fuel, so they can't just be like, Oh, I'm just going to
add a million to fuel without putting gallons.
You know, what we do is we say, OK, well, you're going to say how many gallons that you're going
to add and then we're going to modify the fuel however we want.
So another thing to just point out there is it's not just the a dollar, now we have all the functions,
you can kind of see how they all work together with the class.
So I'm going to end this lecture right here because I don't want to stuff too much information into
this, but we're going to continue in quite a few lectures, going over the rest of kind of the stuff
to do with classes.
And there's a lot more that we actually need to do to have a full on class.
We're going to talk about what these get initialized to in the beginning, when the object gets created,
what values they have in them.
We're also going to talk about how, of course, to make an object.
Right now, all I've said was what is the blueprint, the classes, the blueprint.
But the class is not the object itself.
We have to make an object of the car class, right?
When you have a blueprint of a car, you're like, Oh, great, I know I know what a car has now.
But what if you got to build the car?
You got it.
You can't just, you know, the blueprint isn't what the user buys, right?
Does the user buy like a bunch of pages that are blueprints of a car?
No, they don't.
They buy an actual car, so we got to make the actual car right.
We have to make an instance of a car which would be considered a car object.
Right.
And that's the thing that the user is going to want in the user is actually the one that's going to
make it.
So they're going to make a car object and then they're going to be able to use it based on the blueprints
that we've provided.
So all right, with that, I will see you in the next election where we continue on talking about classes.