Наши программные объекты являются отражением объектов реальности, состояние которых неразрывно связано с поведением. Возьмем для примера мяч. Его состояние можно описать размером, массой и положением. Размер и массу в небольших пределах мы можем изменить подкачивая мяч, а положение -- пнув его. И в первом и во втором случае воздействие на состояние происходит не прямым изменением параметров состояния, а через поведение мяча, как реакция на взаимодействие с ним. Подкачивая мы увеличиваем количество воздуха внутри оболочки мяча добавляя ему массу и увеличивая давление, которое, растягивая оболочку, увеличивает размер. Пнув же мяч мы прикладываем силу, создающую ускорение зависящее от массы и увеличивающее скорость мяча, а наличие скорости приводит к изменению положения. Отражение этой неразрывной связи в программировании называют инкапсуляцией. Для ее реализации языки программирования получили возможность объединять в единой структуре (классе) переменные и функции, работающие с ними, а также модификаторы видимости, обеспечивающие контроль доступа к параметрам состояния и поведению. Таким образом у инкапсуляции есть два аспекта: объединение и контроль доступа, а ее использование обеспечивает согласованность состояния объекта. Часто инкапсуляции приписывают сокрытие реализации, но это не так. Классы не могут скрыть реализацию, поскольку ее имеют.
Степень инкапсуляции мы устанавливаем сами, и можем как полностью от нее отказаться, так и полностью скрыть состояние. Это всегда компромисс между стремлением иметь согласованное состояние и сложностью реализации этого. Вернемся к мячу.
Белый мяч не инкапсулирует свое положение. Мы можем изменять положение мяча задавая новый объект через свойство MassCenter или меняя (x, y, z) у существующего. Более того, сохранив ссылку на объект, переданный в конструктор, мы можем менять положение и через нее. И никто нам не мешает использовать эту ссылку более одного раза, получив еще один забавный способ изменения положения. Веселья добавляет то, что интеллектуальная подсказка именитой среды разработки выдает именно этот вариант реализации конструктора. Незамеченная ошибка или фанатичное стремление к внедрению зависимостей?
В отличии от Белого, Черный мяч почти полностью инкапсулирует положение ценой дополнительных расходов на создание и последующее удаление копий центра масс. Почти из-за рефлексии, но против неё нет приёма.
Мы можем пойти на компромисс, все же выдавая ссылку на внутренний объект центра масс, но ограничивая ее функционал с помощью интерфейса.
Использование приватной локальной реализации точки тоже пример инкапсуляции -- мы инкапсулируем зависимость. Кроме того, это блокирует возможность приведения ссылки к изменяемому типу или доступ через dynamic.