Про полиморфизм в данном контексте понял (в примерах до меня лучше доходит), a значение и так знал :о).

Но
Проверка внутри сеттера как раз и есть "проблеск инкапсуляции", мы не сможем впихнуть в объект невпихуемое, тем самым не сломаем "капсулу".
При этом в сеттер тоже можно много чего напихать.
Например (грубый), если у массива сделать сеттер length, по которому попить или пушить элементы до нужной длины. Нам совсем не нужно знать о том, как он при этом реорганизуется внутри и всё в этом духе.

У меня ощущение, что мы говорим об одном и том же, но смотрим на конкретне примеры немного с разных сторон.

полиморфизм

к сожалению, только через акцессоры мы можем задать интерфейс для свойств

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

пример:
изменяя извне свойство width у спрайта мы не задумываемся , что при этом, как такового, свойства то и нет, и мы меняем матрицу трансформации, при запросе аналогично - мы всего лишь узнаём лишь какое-то вычисляемое значение.
т.е. по сути _width наверое и нету никакого (а если и есть, то только для кэширования вычислений)

@Psycho Tiger
В том что доступа к данным у тебя нет, у тебя есть доступ только к методам для их получения/изменения. Опять же, ты не знаешь как они работают. Это и есть инкапсуляция.

@Bee
Обе точки зрения равноправны. Ибо переменную переопределить нельзя.

@Котяра
С какого перепуга VO стали что-то диспатчить? ByteArray диспатчит? Нет. А он как и любое VO есть тупо набор данных.

Согласен, но чтобы не писать лишнюю обёртку над vo, прописать диспетчеризацию явно или через [Bindable], считаю нормальной практикой. VO от этого не становится чем то большим.

Обычно VO использую без диспетчеризации, только для определения типа. А проверку и диспетчеризацию оставляю для ProxyData, который эти VO содержит.

т.к. именно ProxyData генерирует окончательные события.

Напомните плиз, от какой фразы образовано сокращение VO?

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

Я согласен с Вами. Но я еще не испытывал неудобств следуя своему методу: содержать в VO исключительно данные, без малейшего функционала.

На примере тех же Point и Rectangle хорошо видно, как избыточный функционал напрягает. Может я и ошибаюсь, но мне кажется, каждому хотя бы раз приходило в голову желание сделать минималистические аналоги, которые были бы просто хранилищем нескольких переменных. Потому как для общения разных классов и их методов, да и для хранения данных в этих классах, ничего кроме координат и ширины/высоты от этих Типов не нужно. Но рано или поздно упираешься в то, что придется преобразовывать таки свои пойнты/доты/пункты/позишны в стандартный Point, чтобы вызвать наконец стандартный метод. Что мешало заключить всю эту богатую функциональность точки в какой-нибудь другой класс в либе geom, для меня лично загадка. Я не люблю мультитулы и монстров. Воздушный хрупкий Пойнт из двух свойств мне больше по душе. А набор методов для работы с ним мог бы прекрасно жить в наборе методов, принимающих эти легкие пойнты и ректанглы для обработки.