А теперь возникает другой вопрос. Зачем они используются, если ломают

инкапсуляцию?

а как?

Кто они?

Ну так, инкапсуляция же не даёт доступ к членам класса другим классам. Разве нет?

Они как раз дополняют инкапсуляцию, а не ломают ее. Увеличивают ее возможности без нарушения принципов.

так, со мной это редко, но ты меня запутал.

Так выше уже об этом говорили

Ну, может, я не правильно понял значение инкапсуляции.

Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают.

инкапсуляция не дает тебе менять данные объекта класса безконтрольно.

Инкапсуляция - обобщенная парадигма, в рамках которой семантически сцепленные компоненты помещаются в некоторую готовую к их содержанию сущность. Эта сущность берет на себя ответственность за предоставление доступа к своему содержимому.

не даёт, да

А, я то думал, что инкапсуляция вообще запрещает изменять данные вне класса.

Ну , в общем так, да, проблема-то в чём?

ну, тогда бы это был мир функционального программирования :) там все объекты иммутабельны

Проблемы нет, просто, задумался.

Так нет же, в этом и идея. Мы как раз пытаемся демонстрировать, что дает, просто в строго заданном порядке.

Что кто даёт? Я запутался.

Я тоже не догоняю.

но ведь у объекта может быть какой-то internal state

Вот мне что не понятно, так это то, ЧТО ТАМ ВООБЩЕ может быть непонятно.

такой педагог в тебе пропадает

Проблема моего непонимания заключалась в том, что я думал, что инкапсуляция ПОЛНОСТЬЮ запрещает доступ к члена класса из вне.

public - доступ всем protected - доступ только МНЕ и наследникам private - доступ только МНЕ! Всё

Инкапсуляция не обязана отрезать сущность от внешнего контекста - достаточно только ограничить множество их взаимодействий. В этом и была основная идея, поскольку искомый товарищ упорствует и желает рассматривать инкапсуляцию только с т.з. полной изоляции.

ДА, ТАК И ЕСТЬ, ПОЛНОСТЬЮ ЗАПРЕЩАЕТ!

Да

Так если инкапсуляция ПОЛНОСТЬЮ запрещает, тогда зачем на геттеры и сеттеры? Они же ломают само понятие инкапсуляции.

Нихера они не ломают, с чего бы?

Если инкапсуляция подразумевает ПОЛНЫЙ запрет на взаимодействие с членами класса, а сеттеры позволяют ВЗАИМОДЕЙСТВОВАТЬ с членами класса, тогда тут несостыковочка.

А это потому что Вы отождествляете приватность некоторой сущности и факт ее инкапсулированности. Сущность может оставаться инкапсулированной даже если она доступна из внешнего контекста, пока таковой доступ опосредован и контролируется разделяющей средой (ака классом).

С какого перепоя ты решил, что ломают? Сеттер -- это же не значит, что есть доступ к мемберу. (его вообще нет), ты можешь только вызывать метод.

Ну сеттер если тоже будет в привате, то и к ниму ты не обратишься

Так и есть, полное взаимодействие с ЧЛЕНАМИ ДАННЫХ и запрещается, а ты МЕТОД вызываешь. Если метод приватный, то ты его НЕ ВЫЗОВЕШЬ, если публичный -- вызывай сколько хочешь.

Ну так сеттер - это метод, который позволяет изменять значение члену класса.

Давай начнём с того, что выясним, с чего ты вообще решил что он что-то меняет -- этот метод. На нём написано?

Сеттер же -- член этого класса, часть класса. Ему можно, вот он и меняет.

ты можешь всех обмануть: void set(int value) { connection.builder().from("юстас").to("алекс").build().send("они вызвали меня с новым значением " + value + "шеф, все пропало"); }

как видишь, никто даже не узнал, что ты написал шпионское ПО

Ты же должен как-то данные менять, в этом и состоит суть программы. Она берёт данные и обрабатывает. Если она ничего не будет менять, она бесполезна.

никогда ещё штирлиц не был так близок к провалу

Имея сеттер, ты даже не обязан иметь соответствующий член данных. Так что что он там меняет -- это внутреннее дело класса. Это и есть инкапсуляция.