When you enter a software development career, you will likely share your code with other programmers. If they use your code in unexpected ways, it can be disappointing to find that they changed variables and called methods that you didn't intend for them to use. To avoid this, you can use encapsulation — a set of tools provided by most object-oriented programming languages — to specify which parts of your code are accessible to the public and which are not.
Encapsulation
Encapsulation refers to bundling data with the methods operating with it while restricting direct access to some components.
When we're programming using an object-oriented language, we are in control of all modifications. The object doesn't change by itself; it always needs a reason to do so, which is usually some action that you're performing on it. To understand it better, you can think of the wall color. What is more effective, to rewrite this attribute manually, or to call the paintTheWall() method? The second way looks more clear as the wall can't change its color by itself!
We recommend you to be very careful, as direct access to the inner data of an object is similar to moving gears in a clock mechanism to set the time: you can break it easily! Instead of getting inside, you can use the knobs the manufacturer has designed for you. As you can see, it is better to hide the details crucial for operation from a common user.
It seems like it's a hard task to change an object, but maybe there is a simple solution for this routine.
Getters and setters
Being a programmer is like being an engineer. You can create a class with some data that no one can change, while it is also possible to provide it with some safety mechanism prohibiting any modification. For the data that should never change from the outside, let's not allow any ways at all. It seems reasonable to keep the user away from dangerous and unpredictable operations.
The easiest way to allow access to data while maintaining control over changes is to create methods to get and set data, which is also a common practice in many object-oriented languages. These methods are known as getters and setters. Some argue that these methods allow arbitrary change to an object and are therefore unnecessary, but there are clear benefits to allowing change through such methods. Using setters, we can specify that there should be an actor to change an object. Additionally, with the set() method, we can check if the new data is correct and doesn't break the integrity of the object. If it does, we can prevent the operation from happening.
As we said, most but not all languages use setters. What are the other methods to change an object?
Domain-specific methods
Assume that you're working on the Clock class. What operations can you provide a user with to change the time? It can be setTime(), but if the user wants to change the time more granularly, you can create such methods as addHour(), addMinute(), addSeconds(). Now we can emulate the real action for our domain of knowledge.
Users may also want to adjust the timezone without setting the minutes and seconds. If you're following the main idea, you can propose a solution which is creating a method changeTimezone(). It's more clear for a user how to do it now. A user passes a timezone or even a city, and the method does the rest.
Now you know how to control the changes of the data through methods, but what about protecting the attributes of our classes?
Protecting data
The problem of protecting data doesn't have a universal solution for all programming languages. Some of them give you keywords to restrict access to the attributes of a class. Others can have name conventions or even name mangling. You should read the documentation of your language to figure out how to do it properly.
Some languages use keywords to set the visibility for the fields of a class. With their help, you can choose the exact scope where you can access the variable. The other method is naming conventions. For example, you can set up a rule that all the attributes starting with a capital letter are public, but all the variables starting with a lowercase letter are accessible only in the inner scope.
Name mangling is a principle of changing a field name for external access. Assume that your class has an attribute minutes, and for all the other scopes out of this class, this attribute will be available as do_not_use_these_minutes. It doesn't restrict access to an attribute but shows a red flag to do so.
Conclusion
The object-oriented approach implies interacting with objects through the methods. You can use getters, setters, and domain-specific methods to provide access to the attributes. You can control the scope of visibility of all the attributes by applying the rules for your language.
You need these instruments to hide the inner implementation of an object and to make it easier to maintain.