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

[alatar]

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

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

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

[Wolsh]

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

[Inet_PC]

Воздушный хрупкий Пойнт из двух свойств мне больше по душе.

Аналогично

[strangedk]

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

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

[alatar]

Как это "обратные"?

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

Добавлено через 4 минуты

допустим даже расширив тот же VO.

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

[strangedk]

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

Блин опять этот холивар вокруг VO.

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

[Котяра]

Блин опять этот холивар вокруг VO.

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

[tofflife]

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

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

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

var value:Object = anyObject.something;

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

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

anyObject.something = null

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

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

public function getData():IData{
  return m_data;
}
 
public function setData(data:IData):void{
  assert(data != null, "blabla");
  m_data = data;
  update();
}

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

function myFunction():void{
  var value:IData = data;//непонятно, читается переменная или свойство?
}

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

function myFunction():void{
  var value:IData = getData();//явно вызывается функция
}

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

[goodguy]

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

Как-то не убедительно. Даже используюя стиль джавы можно намалякать такого хлама, что так же будет непонятно, что и где.

//непонятно, читается переменная или свойство?

А не один ли фиг что там читается? Тут явное присвоение. Какая разница получен результат от функции или из переменной.

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

Значит оно автоматически сконвертируется в допустимое.

[Psycho Tiger]

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