Агрегация и осведомленность

[lusever]

Тот же механизм есть в google closure library в методе registerDisposable или addChild. Если сделать dispose родителя, то все потомки уничтожатся. Но там еще ко всему можно переместить ребенка не уничтожая его. В этой реализации я так понимаю нельзя будет сделать.

[enepomnyaschih]

Про registerDisposable не знал. Громкое заявление про уникальность jWidget убрал.

Давайте обсудим. Судя по реализации, в google closure library ассоциированные объекты уничтожаются в порядке добавления. На мой взгляд, это неудобно. Пример:

this.registerDisposable(this.p = new Provider()); // какой-то провайдер
this.registerDisposable(this.c = new Consumer(this.p)); // какой-то консюмер
this.dispose();

Сначала будет уничтожен провайдер, а потом консюмер. Между этими двумя действиями у консюмера будет битая ссылка на провайдер. Не проблема, если можно просто поменять местами два вызова registerDisposable, но это не всегда можно сделать так просто. Чем они обосновали такую реализацию?

Есть ли аналог агрегирующего свойства и коллекции?

Переместить ребенка, не уничтожая его, можно. Как это правильно сделать, зависит от того, куда вы планируете его перемещать. Если просто хотите поменять порядок компонентов в едином контейнере, поместите их в агрегирующий массив и воспользуйтесь методом move. Если вы, скажем, реализуете drag & drop между различными контейнерами, создайте все перетаскиваемые элементы заранее в компоненте страницы или формы, зарегистрируйте их в агрегирующем словаре, а потом сделайте, чтобы контейнеры брали перетаскиваемые элементы из этого словаря. Поскольку элементы из словаря не удаляются при перетаскивании, все будет работать хорошо.

[ntstv]

Сначала будет уничтожен провайдер, а потом консюмер. Между этими двумя действиями у консюмера будет битая ссылка на провайдер

Можно написать так:

this.registerDisposable(this.p = new Provider()); // какой-то провайдер
this.c = new Consumer(this.p); // какой-то консюмер
this.p.registerDisposable(this.c);
this.dispose();

[enepomnyaschih]

Согласен, но пришлось немного подумать, чтобы обнаружить проблему и найти ее решение. Из-за такой мелочи код на продакшене может упасть в самый неожиданный момент. Уничтожай GCL ассоциированные объекты в обратном порядке, registerDisposable был бы надежнее. Просто делюсь мнением.