Почти все это показывает фундаментальное неправильное понимание инкапсуляции и того, как она применяется.
Первоначальный ответ, что вы нарушали инкапсуляцию, просто неверен. Вашему приложению может потребоваться просто установить значение сыра в холодильнике вместо увеличения / уменьшения или добавления / удаления. Кроме того, это не семантика, независимо от того, как вы ее называете, если вам нужно получить доступ и / или изменить атрибуты, вы не нарушаете инкапсуляцию, предоставляя их. Наконец, инкапсуляция на самом деле не о «сокрытии», а об управлении доступом к состоянию и значениям, которые не должны быть открытыми или управляемыми вне класса, при этом предоставляя их тем, кто должен, и выполняя задачу, доступную внутри.
Метод получения или установки не нарушает инкапсуляцию, когда есть законная необходимость получить или установить значение. Вот почему методы могут быть обнародованы.
Инкапсуляция - это хранение данных и методов, которые изменяют эти данные непосредственно в одном логическом месте, классе.
В этом конкретном случае явно необходимо изменить стоимость сыра в приложении. Независимо от того, как это делается, через get / set или add / remove, при условии, что методы инкапсулированы в классе, вы следуете объектно-ориентированному стилю.
Для пояснения я приведу пример того, как нарушается инкапсуляция, предоставляя доступ независимо от имени метода или логического выполнения.
Скажем, у вашего холодильника есть «срок службы», просто несколько тиков, прежде чем холодильник перестанет работать (ради аргумента, холодильник не может быть отремонтирован). По логике вещей, пользователь (или остальная часть вашего приложения) не сможет изменить это значение. Это должно быть частным. Он будет виден только через другой открытый атрибут, известный как isWorking. Когда время жизни истекает, внутренне холодильник устанавливает isWorking в false.
Выполнение обратного отсчета времени жизни и переключение переключателя isWorking - все это происходит внутри холодильника, ничто снаружи не может / не может повлиять на процесс. isWorking должен быть только видимым, поэтому получатель не нарушает инкапсуляцию. Однако добавление методов доступа к элементам процесса жизни нарушит вашу инкапсуляцию.
Как и большинство вещей, определение инкапсуляции не буквальное, а относительное. Должны ли вы видеть Х вне класса? Должны ли вы быть в состоянии изменить Y? Все ли это относится к вашему объекту здесь, в этом классе, или функциональность распространяется на несколько классов?
putCheese
добавил бы сыр в холодильник иtakeCheese
удалил бы его - это доменные абстракции (более высокого уровня), а не получатели и установщики поля объекта (которые являются (низкоуровневыми) абстракциями компьютерного программирования).