Almost all of this shows a fundamental misunderstanding of encapsulation, and how it applies.
The initial response that you were breaking encapsulation is just wrong. Your application may have a need to simply set the value of cheese in the fridge instead of increment/decrement or add/remove. Also, it is not semantics, no matter what you call it, if you have a need to access and/or change attributes you don't break encapsulation by providing them. Finally, encapsulation is not really about "hiding", it's about controlling access to state and values that should not need to be public or manipulated outside of the class, while granting it to those that should and performing the task made available internally.
A getter or setter doesn't break encapsulation when there is a legitimate need to get or set a value. This is why methods can be made public.
Encapsulation is about keeping data and the methods that modify that data directly together in one logical place, the class.
In this particular case, there is clearly a need to change the value of cheese in the application. Regardless of how this is done, via get/set or add/remove, as long as the methods are encapsulated in the class you are following the object oriented style.
For clarification, I'll give an example of how encapsulation is broken by providing access regardless of method name or logical execution.
Say your fridge has a "lifetime", just a number of ticks before the fridge is no longer operational (for the sake of argument, the fridge can't be repaired). Logically there is no way a user (or the rest of your application) should be able to change this value. It should be private. It would only be visible through say a different public attribute known as "isWorking". When the lifetime expires, internally the fridge sets isWorking to false.
The execution of the lifetime counting down and its flipping the isWorking switch is all internal to the fridge, nothing outside could/should be able to effect the process. isWorking should only be visible, thus a getter does not break the encapsulation. However adding accessors for elements of the lifetime process would break your encapsulation.
Like most things, the definition of encapsulation is not literal, it's relative. Should you be able to see X outside of the class? Should you be able to change Y? Is everything that applies to your object here in this class or is the functionality spread across multiple classes?