Presque tout cela montre une incompréhension fondamentale de l'encapsulation et de la manière dont elle s'applique.
La réponse initiale selon laquelle vous rompiez l'encapsulation est tout simplement fausse. Votre application peut avoir besoin de simplement définir la valeur du fromage dans le réfrigérateur au lieu d'augmenter / diminuer ou d'ajouter / supprimer. De plus, ce n'est pas de la sémantique, peu importe comment vous l'appelez, si vous avez besoin d'accéder et / ou de modifier des attributs, vous ne rompez pas l'encapsulation en les fournissant. Enfin, l'encapsulation ne consiste pas vraiment à "cacher", il s'agit de contrôler l'accès à l'état et aux valeurs qui ne devraient pas avoir besoin d'être publiques ou manipulées en dehors de la classe, tout en l'accordant à ceux qui le devraient et en effectuant la tâche mise à disposition en interne.
Un getter ou un setter ne rompt pas l'encapsulation lorsqu'il existe un besoin légitime d'obtenir ou de définir une valeur. C'est pourquoi les méthodes peuvent être rendues publiques.
L'encapsulation consiste à conserver les données et les méthodes qui modifient ces données directement ensemble dans un seul endroit logique, la classe.
Dans ce cas particulier, il est clairement nécessaire de modifier la valeur du fromage dans l'application. Quelle que soit la façon dont cela est fait, via get / set ou add / remove, tant que les méthodes sont encapsulées dans la classe, vous suivez le style orienté objet.
Pour plus de précision, je vais donner un exemple de la façon dont l'encapsulation est rompue en fournissant un accès indépendamment du nom de la méthode ou de l'exécution logique.
Supposons que votre réfrigérateur ait une "durée de vie", juste un certain nombre de tiques avant que le réfrigérateur ne soit plus opérationnel (pour des raisons d'argument, le réfrigérateur ne peut pas être réparé). Logiquement, il est impossible qu'un utilisateur (ou le reste de votre application) puisse modifier cette valeur. Cela devrait être privé. Il ne serait visible qu'à travers, par exemple, un attribut public différent appelé "isWorking". À l'expiration de la durée de vie, le réfrigérateur fonctionne en interne et fonctionne à faux.
L'exécution du décompte à vie et son actionnement de l'interrupteur isWorking sont toutes internes au réfrigérateur, rien à l'extérieur ne devrait / ne devrait pouvoir effectuer le processus. isWorking ne doit être visible que par conséquent, un getter ne rompt pas l'encapsulation. Cependant, l'ajout d'accesseurs pour des éléments du processus de durée de vie briserait votre encapsulation.
Comme la plupart des choses, la définition de l'encapsulation n'est pas littérale, elle est relative. Devriez-vous voir X en dehors de la classe? Devriez-vous être en mesure de changer Y? Est-ce que tout ce qui s'applique à votre objet ici dans cette classe ou la fonctionnalité est-elle répartie sur plusieurs classes?
putCheese
ajouterait du fromage au réfrigérateur ettakeCheese
l'enlèverait - ce sont des abstractions orientées domaine (de niveau supérieur), plutôt que des getters et setters de champ d'objet (qui sont des abstractions de programmation informatique (de bas niveau)).