Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
Next up is the idea of Encapsulation. Think capsule like a space capsule or medication capsule or a food container. This is the idea of surrounding something, not just to keep the contents together, but also to protect those contents. Now, in Object Orientation, this first refers to the idea of taking our attributes and then taking our behaviors and bundling them together in the same unit, the same class. But it's really more than that. We also want to restrict access to the inner workings of that class or any objects based on that class, and this is referred to as information hiding or data hiding.
The principle is that an object should not reveal anything about itself except what is absolutely necessary for other parts of the application to work. Let me give you a simple specific example. If we have this bank account class, well, we don't want some other part of our application to be able to reach in and change the balance of any object without going through the deposit or the withdrawal behaviors. Perhaps those behaviors are supposed to perform auditing and logging of deposits and withdrawals.
So we can hide that attribute, that piece of data. We can control access to it so that it's only accessible from inside that object itself. Sure, we can use the deposit and withdrawal methods from other parts of the application, and they can change the balance, but it can't be directly changed from outside the object. This is one that's also referred to with the idea of black boxing. We are closing off more and more of the inner workings of the object except for those few pieces we decide to make public for, say, input and output.
Think of using a telephone. You want your interaction with a telephone to be as simple as possible. Just use the keypad to make a call. But you don't want to care about how it works internally. If the inner workings of your telephone completely changed, it wouldn't matter as long as you still have the same buttons to press. One of the main benefits with Object Orientation is that it allows us to more safely change the way the object works because we've hidden this data. Perhaps we started off by storing that bank balance as a single floating-point number, and then we decide a little later that it's much better to store it as two integers, one for dollars and one for cents.
Now, if we've restricted direct access to that piece of data, we only have to worry about this one class, and we don't have to worry about breaking the other 17 parts of the application that might have been reaching in to grab it. Now, a common question from folks new to Object-Oriented Programming is but if I am writing these classes, why would I want to hide my own code from myself? And here's the thing, it's not about being secretive, that's not our point. It's about reducing dependencies between different parts of the application, that a change in one place won't cascade down and require multiple changes elsewhere. But how much should you hide? Well, the rule is as much as possible.
As we will see, different languages have different levels of support for this concept, but the idea of encapsulation is that you enclose, you encapsulate your object's attributes and methods, and then you hide everything about that object except what is absolutely necessary to expose. And the effort that we will put in to abstracting and encapsulating our classes can still be very useful when creating other classes, as we'll see with Inheritance.
Get unlimited access to all courses for just $25/month.Become a member