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

Разговаривал я тут с одним хорошим java проггером, его постулат был - никаких публичных переменных, только геттеры и сеттеры.
Собственно хотелось бы обсудить данный вопрос, кто как считает?
Понятно , что с точки зрения полиморфа - только геттеры и сеттеры, с другой стороны если интерфейсность не нужны, то можно и пабликами обойтись !? , и третья сторона медали - Если есть инфо-класс содержащий только перменные и их допустим 100 , наверное тяжко будет вчитываться в такой класс с гет-сетами , нежели только с публик...
Вообщем как работаете Вы ?

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

Мнение принятно, соглашусь. Хотелось бы услышать еще раздумья

Да про интерфейсы я как-то пропустил. Если они нужны, то да - используем акцессоры.

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

Я сюда же.

Есть еще такая концепция деления классов на "классы" и "типы данных". Классы это то, что меняет данные, а типы данных - это набор данных безо всякой логики, то есть безо всякой обработки, без методов. В этом случае как раз нужно использовать public, но в случае с Классами такое встречается крайне редко: каждый Класс старается "защитить свои инвистиции", свои рабочие данные, и не позволить изменять их извне. Но исключения конечно есть, тот же Point.

Добавлено через 6 минут
Вот как раз в контексте этой концепции ТипыДанных по определению не имеют интерфейса (что абсолютно разумно, так как они ничего не делают). И опять же, есть забавное исключение - IBitmapDrawable, маркерный интерфейс, "описывающий" не что объект делает, а что можно сделать с ним. Показательно, что он маркерный, то есть абсолютно пустой.

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

Нене, ТипыДанных служат для передачи данных (как обычно используется Ректангл и Пойнт для передачи параметров функциям), и ничего диспатчить они не собирались :) То, о чем говоришь ты – это уже Модель))

Часто использую публичные переменные в тех местах, где это не критично. Если сеттер только и делает то, что задает значение переменной, а геттер ее возвращает, то всегда использую просто public переменные где это возможно. К ним и доступ осуществляется быстрее, чем через геттеры.

А в чем она проявляется? Вот 2 варианта. Разницы нету.
Использую акссесоры там, где нужно. Если акссесор не нужен - не использую.

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

З,Ы - Дело было поздней ночью, мозги просились в койку, глаза видели сны.

В вашем примере нет. Я про такое

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

Или я опять забыл, что такое инкапсуляция и полимрфизм.

Думаю, это тут и так все понятно ;)

Только сеттеры =)

А по скорости работы через геттеры/сеттеры против полей класса нет информации? Где-то на форуме было, что при неоднократном обращении к полю, выгоднее его закешировать в локальной переменной.

Да. Оператор dot - тоже оператор )
А аксессор - это всё таки почти метод.
Инкапсуляция = сокрытие реализации. Проверка на значение перед присвоением никак не скрывает реализацию. Однако, геттер без сеттера скрывает.

Ну да, точно :D Но геттеры позволяют контролировать отдаваемое значение =)
Естественно к переменной доступ быстрее. Тут чистая логика. Или нужно сначало найти геттер, потом найти возвращаемое значение, или же сразу найти значение.

Отликбезьте, пожалуйста, в примерах? Или что понимается под словом "реализация" И чем хороши геттеры сеттеры для "полиморфа" просветите?

вообще, для меня естественно, чтобы выполнялось с одинаковой скоростью при отсутствии проверок, а сеттеры, только лишь синтаксический сахар, для удобства. Но реальность пока где-то рядом. :)

Вот сейчас задумался, насколько уместно словосочетание "сокрытие реализации" здесь.
Вот например возьмем класс Socket. Нам совсем не нужно знать о том, как он поднимает эти соединения и всё в этом духе. Нам не нужно знать, что за поле _buf у него есть (если есть), потому что нам дают вполне полный функционал для работы, а залезя во внутренности мы что нибудь сломаем что нибудь руками. Вот сокрытие того, как класс делает что-то и есть инкапсуляция. Предоставление пользователю только того, чего он не сможет сломать. Соответственно, посему геттер без сеттера это проблеск инкапсуляции - мы запрещаем ему менять какую-то переменную. Но разные проверки внутри сеттера - это штатные ситуации, которые обрабатываются. Это просто код класса.

Полиморфизм, если на пальцах... Ну вот есть класс A, от которого наследуется класс B.
теперь получив где нибудь ссылку на A и вызвав method мы можем увидеть как 1, так и 2. Потому что в ссылку с типом A может попасть класс В. И вот эта штука и называется полиморфизмом.

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

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

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

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

полиморфизм

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не значит, что все не испытывали. Вон у Wolsh обратные неудобства, которые меня никогда не напрягали ;)

Добавлено через 11 минут
Можно конечно придумать новое название для этого явления, что-то типа "Микромодель служащая для типизации параметров и транспорта данных внутри приложения". Но кроме дополнительной функции уведомления о изменении свойств и, как правило, большего срока жизни это все тот же VO.

Как это "обратные"? Именно те самые, то что в VO напихали всякого функционала, который нужен только в определенных,, я бы сказал – специфических случаях. И вот я вынужден гонять этих монстров с кучей методов там, где мне нужна только пара (х, у). И не заменить на свой класс-VO, потому что все стандартные методы, так или иначе связанные с графикой, требуют стандартные пойнты и ректанглы.

Аналогично

Абсолютно согласен, добавить функционал dispatch там где он будет нужен - всегда можно, допустим даже расширив тот же VO.

Обратные от моих с Котярой :)

Добавлено через 4 минуты
Можно и расширив, но это опять же добавит еще экземпляр диспатчера в дополнение к объекту. Если события необходимы, то какой смысл плодить дополнительные объекты, типа прокси и диспатчера, если можно VO сразу отнаследовать от диспатчера.
Блин опять этот холивар вокруг VO.

Просто всегда максимально стараюсь отделить данные от функционала) и всего-то.

Да вроде выяснили же.

Мне пофик)
В 99% случаев мне не нужен простой VO, а нужно сдледить за его изменением.
Лично Я всё равно называю его VO.
В as1/as2 была хорошая вещь watch.
Мне её не хватает :confused:

согласен с волшем. Паблик переменные - зло, особенно, если проект средних размеров (от 20000 строк и более),

Зло, потому что утрудняют изучение кода.

Вот что значит данная запись?

получения ссылки на функцию? Или же получение некой переменной? А можно ли записать туда что-то?

Ещё печальнее обстоят дела, когда происходит запись в объект:

это проперти, или паблик-переменная? Стоит ли пологаться на something? ведь, возможно, null - недопустимое значение для неё.

Поэтому я считаю, что лучшее средство - это ВСЕГДА писать геттеры и сеттеры. И не эдобовские геттеры и сеттеры, а джавовские, т.е:

поскольку в таком случае, когда

вполне ясно, что

В довершение ко всему, как вы собираетесь отлавливать изменения в паблик-переменных?

Как-то не убедительно. Даже используюя стиль джавы можно намалякать такого хлама, что так же будет непонятно, что и где.
А не один ли фиг что там читается? Тут явное присвоение. Какая разница получен результат от функции или из переменной.
Значит оно автоматически сконвертируется в допустимое.

Меня всегда умиляли случаи в вакууме.
Как будто программирование это 40 одинаково красных кнопок и в каждый момент времени надо нажать одну единственно верную, иначе всё: хана, взрыв, кишки, трупы, плохой запах изо рта.
Не бывает переменных something. Бывают осмысленные переменные. По названию которых уже многое понятно. Если при чтении кода мы видим что туда происходит запись, то я гарантирую, что туда можно записать. Если код пишется и не понятно, можно ли туда что-то записать — то круто будет, например, узнать. Я вот доверяю себе: и если я сомневаюсь, что это валидное значение - я открою этот класс и посмотрю. Или спрошу. Это, конечно, приятно, если при присвоении я получу RTE, что значение недопустимое, но ещё приятней пиша код понимать, почему я могу, а почему не могу туда что-то записать.