[Appleman]

Друзья, ситуация:

1. Имею в Модели слот экипированного персонажу объекта (не обязательно предмет). Сам такой объект имеет свойства и статусы, отображаемые во Вью. Их состав может меняться в зависимости от типа;
2. При изменении свойств/статусов экипированного объекта Модель посылает событие, Вью по нему обновляет: выводит иконки рядом с окном экипированного.
3. Когда объект удаляется из экипированного, то работает следующая логика: если этот объект относится к самому персонажу (например, руки), то все статусы скрываются в окне экипированного и одновременно выводятся в окне персонажа, уже рядом с его портретом. А если экипированный объект - это предмет, то ничего никуда не нужно выводить.

Основанием для обновления Вью является событие от Модели. Сейчас оно приходит только при изменении значений свойств объектов. Поэтому при смене экипированных объектов события отправлены не будут, т.к. никакие их свойства не изменились. ДУмаю, как реализовать нужное мне поведение. Есть 3 варианта, но ни один мне не нравится:

1. На уровне Модели проверять, что за объект имеем и либо принудительно посылать соответствующие события в момент, когда он удаляется из экипированного, либо нет. Гарантированно даст нужный результат, но в моём понимании, нарушает принцип MVC, т.к. с т.з. Модели, совершенно по фигу, какие объекты как будет отображать Вью.
2. Сделать паблик в классе экипируемых объектов типа forcePropsRecheck(), который будет повторно посылать события на обновления Вью. Во Вью проверять, что за объект удаляется из экипированного и при необходимости дёргать этот паблик-метод. Тоже будет работать, но вроде как вмешательство в Модель со стороны Вью, хотя с т.з. состояния Модель не меняется. Только события переотправляет.
3. Всегда посылать события на обновления свойств и статусов экипируемого объекта из Модели: что при добавлении , что при удалении. Во Вью усложнять алгоритм обработки этих событий и по месту разбираться, что за объект, экипирован он или уже снят и т.д. Такой подход выглядит как самый правильный с т.з. принципов MVC, но самый геморройный.

Просьба прокомментировать. Спасибо.