From here:
Having getters and setters does not in itself break encapsulation.
What does break encapsulation is having a getter and a setter for
every data member (every field, in java lingo). That is one step away
from making all data members public.
The point of encapsulation is not that you should not be able to know
or to change the object's state from outside the object, but that you
should have a reasonable policy for doing it.
Consider an example of a class Person. Let's say a person has a name,
a social security number, and an age. Let's say that we do not allow
people to ever change their names or social security numbers. However,
the person's age should be incremented by 1 every year. In this case,
you would provide a constructor that would initialize the name and the
SSN to the given values, and which would initialize the age to 0. You
would also provide a method incrementAge(), which would increase the
age by 1. You would also provide getters for all three. No setters are
required in this case.
In this design you allow the state of the object to be inspected from
outside the class, and you allow it to be changed from outside the
class. However, you do not allow the state to be changed arbitrarily.
There is a policy, which effectively states that the name and the SSN
cannot be changed at all, and that the age can be incremented by 1
year at a time.
Now let's say a person also has a salary. And people can change jobs
at will, which means their salary will also change. To model this
situation we have no other way but to provide a setSalary() method!
Allowing the salary to be changed at will is a perfectly reasonable
policy in this case.
By the way, in your example, I would give the class Fridge the
putCheese() and takeCheese() methods, instead of get_cheese() and
set_cheese(). Then you would still have encapsulation.
You can also refer: Why getter and setter methods are evil
