Очистка Оверрайдов

[in4core]

Например addChild , tabIndex ... да много всяких. а оставить только x,y,z например.

[gloomyBrain]

возможно автору и не требуется его на сцену добавлять

Да. Отличный выходит класс отображения, если его нельзя отобразить =)

Второй вариант - объект таки является "чистым" UI, но при этом не хочется, чтобы были видны детали реализации. В этом случае спасают функции:

Тут есть 2 варианта
1) Предоставить геттер для того, вокруг чего мы делаем обертку. Это явно пахнет бессмысленностью
2) Возвращать при каждом запросе новый экземпляр DO, сформированный исходя из данных в обертке. Но это нифига не экономно и идеологически криво.

[i.o.]

ну вот вроде как можно убрать из автокомплита ненужные методы / свойста / события с помощью метатега [Exclude(name=, kind=)]
Только я вот сейчас тыкаюсь и ничего не получается.. Может кто подскажет как его правильно применять?

[mayakwd]

http://nondocs.blogspot.com/2007/04/...taexclude.html

Если ничего не выходит - значит ide просто его не воспринимает :-)

[i.o.]

FlexBuilder 2 / 4. Не работает (не исключаю что делаю что-то не так). Создал новый ActionScript Project и добавил класс с эксклудами:

package
{
	[Exclude(name="someMethodC", kind="method")]
	[Exclude(name="somePropertyA", kind="property")]
 
	public class SomeClassA
	{
 
		public function SomeClassA()
		{
		}
 
		public function get somePropertyA():Number
		{
			return 0.0;
		}
 
		public function someMethodA():void
		{
 
		}
 
		public function someMethodB():void
		{
 
		}
 
		public function someMethodC():void
		{
 
		}
	}
}

далее в мейне пишу:

var a:SomeClassA = new SomeClassA();
a.|;

И тут в автокомплите показаны все методы и свойства. Т.е ничего не исключилось...

[Psycho Tiger]

Как по мне — единственное верное перекрытие метода было в LoaderInfo, dispatchEvent. Возможно верное — в Loader. Я бы вообще не наследовал его от DisplayObject. По поводу Security RTE по обращению к content, но не обращению к Loader, конечно, путаница: но ведь от BitmapData#draw летит ошибка, без явного обращения к content. Это, кстати, приводит нас к выводу о рекурсивном поиске детей при снятии изображения; надо будет перекрыть content, выводя trace... Займусь, у меня как раз зреет статья "Самые бессмысленные и бесполезные факты и трюки".
Но оба этих случая, в принципе, можно назвать оправданными. Перекрытие функционала ради полного избавления от возможной ошибки или хака (чего бы стоил диспатч Event.COMPLETE в LoaderInfo!).
А какая потребность в Вашем случае связывать руки себе?

[maxkar]

Сообщение от gloomyBrain

Тут есть 2 варианта
1) Предоставить геттер для того, вокруг чего мы делаем обертку. Это явно пахнет бессмысленностью

Правильно. Зачем получать из display object то, что именно он отображает? Мы же хотим "DisplayObject", а не что-то более сложное. Геттер там не нужен, подписку на события и все остальное будет делать тот, кто создал себе этот объект. Хочет - будет хранить ссылку на экземпляр. Не хочет - может выкинуть данные и использовать только UI.

2) Возвращать при каждом запросе новый экземпляр DO, сформированный исходя из данных в обертке. Но это нифига не экономно и идеологически криво.

Из метода? Да, новый экземпляр. Временем жизни управляет тот, кто вызвал метод "реднеринга" данных. Хочет - пусть кэширует UI и больше не вызвает метод createSomeUI(). Хочет - пусть вызывает и создает новый экземпляр. Экономия здесь ни при чем до тех пор, пока профайлер не покажет, что лишнее создание объектов таки является источником тормозов. Иначе кэширование - это как раз потенцильно лишние проблемы (со временем жизни и т.п.). В чем идеологическая кривость - не понятно. Более того, а если мы хотим отобразить в нескольких местах UI для одних и тех же данных, что делать?

На всякий случай поясню, что createSomeUI() - это не функция обертки. Это либо "свободная" функция (без привязки к классу), либо статическая функция в хелперах. Правильная сигнатура createUIFor(someData : DataForUI) : DisplayObject. Так что я не понимаю, о какой обертке идет речь. В моем примеер её нет. Есть данные, UI и функция из данных в их UI (новый экземпляр).

[incoob]

Если так хочется

связывать руки себе

, то можно использовать интерфейс, в котором будут только нужные вам методы.

public interface IContainer
{
    function get x():Number;
}
public class Container
    extends Sprite
    implements IContainer
{
}
 
public class EntryPoint
{
...
var container:IContainer = new Container();
}

[gloomyBrain]

Это либо "свободная" функция (без привязки к классу), либо статическая функция в хелперах

public function createSomeUI() : DisplayObject {
  return new SomeUI();
}

Так что я не понимаю, о какой обертке идет речь. В моем примеер её нет

Судя по приведенному коду - она там есть. Сложно было понять Вас телепатически =)

По сути, при таком раскладе someData - это модель данных. Соответственно, создаваемый UI - это объект, который зависит от этих данных. Я не вижу смысла делать createUIFor, т.к. у меня может быть несколько вьюх, каждая из которых зависит от различных данных одной и той же модели. И в каждой из этих вьюх я перекрою те методы, которые считаю лишними. Но сделать что-либо универсальное в таком духе - на мой взгляд не получится. Либо это будет неудобно и не "code less, do more"

[maxkar]

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

Так у меня тоже может быть несколько таких методов. createSomeViewFor(data), createAnotherViewFor(data), createThirdView(data). Если нужно - внутри будут использовать наследование. Но это - маловероятно. Вероятнее, они будут использовать какие-то общие методы для отображения частей данных/построения стандартных элементов интерфейса. Наследование различных view друг от друга практически ничего не дает (ну, за исключением пары строк кода для привязки к одной и той же модели).

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