Отказываемся от Public var

[GBee]

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

Но

Соответственно, посему геттер без сеттера это проблеск инкапсуляции - мы запрещаем ему менять какую-то переменную. Но разные проверки внутри сеттера - это штатные ситуации, которые обрабатываются. Это просто код класса.

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

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

[Котяра]

полиморфизм

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

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

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

[gloomyBrain]

@Psycho Tiger

А в чем она проявляется? Вот 2 варианта. Разницы нету.

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

@Bee

Скорее с тз инкапсуляции.

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

@Котяра

Как раз при использовании VO ("типы данных") чаще всего и приходится использовать акцессоры (для диспатча события об изменении)

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

[Котяра]

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

[strangedk]

Сообщение от Котяра

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

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

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

[i.o.]

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

[Inet_PC]

Value Object

[alatar]

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

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

[strangedk]

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

[Wolsh]

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