We know that there's four pillars of Ope, and we learned about encapsulation.
What's the second one?
Well, it's called abstraction.
And abstraction means hiding of information or abstracting away information and giving access to only
what's necessary.
So whatever the user or the programmer or the machine is interested in, that's the only thing we give
access to everything else.
We kind of hide it in a blanket underneath the hood because our users don't have to worry about it.
Let me show you what I mean.
If I go back to our old example here.
So instead of having a dictionary, we actually have a player character with a bunch of methods.
Now abstraction can actually be seen here, right?
When I do player one dot speak.
You're seeing abstraction in action because when I click Run.
I get this drink, but when I call speak, I don't really care how speak is implemented.
All I know is that player one has access to the speak method and I can use it.
Same with when I'm using something like a tuple.
Right.
If I have one, two, three and I do dot here, I can do count to count how many items are in the tuple.
So if I do print and click run.
Well, I have to give it a thing that we're looking for.
In our case, let's look at one and let's add another one in here.
If I click Run.
I get too.
Now, do I need to know how the count method was implemented?
No.
I mean, I can go look into it.
I can look at the Python documentation, maybe the Python code, and understand how it's actually counting
these.
But I don't really need to.
Right.
If we try to understand every single little piece, our head is going to explode.
Sometimes all we need is a method or an attribute and just get access to it without having to worry
about how it's being implemented, which is really, really nice.
The same goes with built in functions, right?
If I do length here and I click run.
I get a length of four, but I don't really need to know how length was implemented in Python.
It's abstracted away from us.
And this is the power of OP.
It abstracts away things that we don't need to care about, or at least it makes us more efficient so
that we know that it works a certain way and we're not wasting our time learning or coding from scratch.
If we had our iPhone, for example, well, the camera feature on an iPhone, it'll be nice for an app
that we build to use it, but we don't need to actually know exactly how the iPhone camera is coated
on an iPhone note.
Instead, the iPhone usually gives us a way to say Camera, dot, take.
Picture.
To actually allow us to take a picture without knowing how the Apple engineers actually coded the camera.
So it's a very powerful concept.
So you're thinking, I think I'll get abstraction.
But let me ask you this.
Could I just do player one.
Dot name equals to let's say, exclamation marks and then player dot run.
Or you know what?
Let's do speak equals to boo.
Make sure it's player one.
Well, if I now print and do player one.
Dot speak and I tried to run this function.
Let's see.
I get string object is not callable because speak has been modified.
Speak has been modified to a string value instead of this actual function that we would have needed.
So that if I run just checking the speak attribute I get boo.
Hmm.
I mean, abstraction is good, but hold on a second here.
This is bad.
If I have a class that I've abstracted away, but anybody can come along.
Any programmer can come along and just remove all my hard work and overwrite it like that.
Isn't that bad?
Let's take a break and explore this topic a little bit more in the next video.