Чья ответственность?

[Appleman]

Друзья!

Судя по соотношению просмотров и ответов на мой предыдущий вопрос, делаю вывод о качестве его формулировки . Попробую ещё раз: компактно и с примерами.

Итак, у меня выполнено действие, вот сигнатура его контруктора:

public function ActionEntity(data: ADEntity, attacker: Character, defender: Character)

Выбранное пользователем действие обрабатывается Моделью по паттерну Стратегия. В нём рассчитаны и доступны результирующие: ID свойства основного эффекта и его размер. Они действуют для того, кто защищался (т.е. имел статус IDs.CH_ACTION_STATUS_DEFENDER). По завершении действия, Модель запускает приватный метод finalazeAction:

private function finalizeAction() : void // Финализирует основное действие
		{
			var propUpdatesArray: Array = new Array[]; 			// Массив изменяемых свойств персонажа
 
			for (var i: uint = 0; i <= _foregroundCharacters.length - 1; i++)
			{
				var ch: Character = _foregroundCharacters[i];
				trace("\nПодводим итоги для " + ch.characterID);
 
				if (ch.actionStatus == IDs.CH_ACTION_STATUS_DEFENDER)
					{
						propUpdatesArray.push(new CharacterPropUpdate(_currentAction.actionData.primaryEffectProp, _currentAction.primaryEffectValue)); // Например, пара: IDs.PROP_HEALTH, -25
// Тут может быть несколько эффектов
					}
 
			}

Последнее, что остаётся сделать, это отправить массив с инструкциями по обновлению значений свойств куда-то, где они будут применены. Вопрос в том, что я никак не могу определиться, куда именно. Есть вариант записать прямо там:

ch.updateProps(propUpdatesArray);

и написать метод внутри класса Character, разместив там всю дополнительную логику (т.к. изменения свойств может подчиняться какой-то ещё дополнительной логике, в т.ч. контекстно-зависимой).

Либо в классе Модели создать новый метод (пишу прямо тут примерно):

private function updateCharacterProps(ch: Character, propUpdatesArray: Array) : void
{
var instruction: CharacterPropUpdate;
var propID: String;
var currentValue: Number;
var newValue: Number;
 
for (var i: uint = 0; i <= propUpdatesArray.length - 1; i++)
{
instruction = propUpdatesArray[i];
propID = instruction.propID;
newValue = instruction.value;
currentValue = ch[propID];
 
// Тут какая-то дополнительная логика, общая для всех изменяемых свойств
 
ch[propID] += newValue;
}

Надеюсь, так понятнее, что я хочу спросить. Буду признателен за комментарии.

[Psycho Tiger]

Мимопроходил, но для меня это звучит так, что у кажого персонажа есть свой инстанс модели, которому кто-то сообщает (видимо, более главная модель?) что его ударили. Внутри модели Character есть этот takeHit метод, который обрабатывает удар и меняет свои свойства (например, понижает здоровье в зависимости от того, насколько этот конкретный персонаж защищен от этого удара). После диспатчит событие, что он изменился, и вьюха этого конкретного персонажа перерисовывается

[Appleman]

Psycho Tiger, спасибо. Мне тоже кажется, что это должен быть метод в модели персонажа.
Правда у меня сегодня ударили, завтра поцеловали. Поэтому результат того или итого действия выглядит как массив из пар: строковый ID свойства, которое изменилось, и число с мерой этого изменения. Так что заранее не известно, потребуется ли takeHit или takeProfit Плюс к этом многие свойства изменяются сами собой со временем (как например, голод постоянно растёт между приёмами пищи) и т.п. В общем, я со всем этим хозяйством запутался.

Пока пришёл к тому, что более главная модель дёргает у Character публичный метод update и отдаёт всё, что претерпело изменения, а он уже будет разбираться, что к чему, и запускать поочерёдно приватные методы с обработкой каждого свойства по отдельности. Как-то так...

[Psycho Tiger]

Да, как вариант. Но мне кажется, что выбранный путь больше навязан "правильной" архитектурой с каких-то статей, форумов. Например, `CharacterPropUpdate` – выглядит как какой-то паттерн.

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

Если есть возможность избежать сложной конструкции "зато через паттерн" и сделать проще, "читаемей", "поддерживаемей" – это путь лучше.