Разработка модели "куклы" персонажа и влияющего на его характеристики "шмота"

[alatar]

Да нет там никакого кошмара, одна функция (рекурсивная или с циклом) в которой ищется объект (A) у которого есть ссылка на удаляемый объект (B). У удаляемого объекта берем ссылку на объект (C) который он декорирует. Потом у B зануляем ссылку на C и вставляем ссылку на C в A. Все.

[gloomyBrain]

Что-то мне кажется что вариант с декоратором - не вариант. Я бы сделал что-то на подобие фильтров. Принципиальная разница в том, что не вот так:

var hero:IHero = new Hero();
hero = new Hat(hero);
hero = new Sword(hero);

а вот так:

var hero:Hero = new Hero();
hero.addBonus("hat boost", new Hat(10));
hero.addBonus("sword boost", new Sword(-3));
 
...
 
hero.removeBonus("sword boost")

Во втором варианте не нужен поиск при удалении.

Хотя, сделать ссылки у самих фильтров типа next-prev тоже можно, если результат применения фильтров зависит от порядка.
Короче да, кроме оптимизации поиска нужного декоратора я к предложению alatar'а ничего не могу добавить =)

[Wolsh]

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

Да нет там никакого кошмара, одна функция (рекурсивная или с циклом) в которой ищется объект (A) у которого есть ссылка на удаляемый объект (B). У удаляемого объекта берем ссылку на объект (C) который он декорирует. Потом у B зануляем ссылку на C и вставляем ссылку на C в A. Все.

Спасибо, получилось)))
Единственно, напрягает необходимость реализации в классе самого итема (который должен поддерживать тот же интерфейс, что и декоратор) геттера и сеттера item))
Декоратору то они нужны для реализации цепочки, но самим шапкам и штанам, пока их не декорировали, они ж совсем без надобности, и вносят некоторую сумятицу.

[alatar]

Можно вынести в отдельный интерфейс для декораторов. Тогда шапки и штаны останутся чистенькими

[Wolsh]

gloomyBrain, сделать-то конечно можно по-разному. Автор в начале темы тоже вполне рабочий вариант предлагал. Но меня интересовал скорее теоретический вопрос про сферический Декоратор в вакууме, а не применительно к данной задаче. Но получилось что и к данной задаче он вполне подходит. Хотя я по-прежнему считаю что сэкономить память он не поможет. Как бы цели слегка не те у паттернов. Они же для облегчения разработки, а не веса экземпляров)). Ну да, когда система отлажена, создание самих декораторов элегантно и прозрачно. Не совсем понятно, стоит ли разворачивать такую систему для трех-четырех бонусов. А если их будет 40, то и с каждым новым декоратором будет наслаиваться 40 новых геттеров-ретрансляторов ради изменения одного свойства((.

Добавлено через 2 часа 6 минут

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

Можно вынести в отдельный интерфейс для декораторов. Тогда шапки и штаны останутся чистенькими

Блин, я тупица! Я так и пытался, но не в ту сторону делал наследование интерфейсов)) Теперь все получилось идеально: только декоратор реализует IDecoratorsChain (который наследует IEnchantable, а не наоборот))), и его сеттер и геттер item имеет тип IDecoratorsChain. Шапкам и штанам оно действительно не потребовалось))
Большое спасибо, alatar!

[Wolsh]

Решил выложить пример, вдруг кому пригодится.
Также, если будут замечания и поправки, прошу поделиться.

Опирался на концепцию The Elder Scrolls IV : Oblivion.
Одежда (и доспехи) может быть зачарована на бонусы к
1) статам (например кол-во магии, выносливости или здоровья),
2) навыкам (например, уровень владения мечом или определенной школой магии)
3) резистам (например, сопротивление огню),
а также на особые постоянные способности, не выражаемые числами (например, дыхание под водой или ночное зрение).
В отличие от одежды, оружие может быть зачаровано только на бонусы к атаке, а точнее только заклинаниями, действующими "на цель".
Таким образом хотя и оружие и одежда являются наследниками класса Предмет и могут быть зачарованы, сами виды бонусов-зачарований совершенно разные, и требуют отдельных линеек декораторов. В примере показан только декоратор для одежды. Оружие должно реализовывать другой интерфейс и подключать другой класс декораторов.