модульность и общий элемент

[in4core]

Снова мучаю вас глупыми вопросами о архитектуре.
Допустим есть у нас некая игра, игра поделена на модули, скажем :
модуль чата, денежный модуль, модуль меню и т.п.
Скажем в модуле денег есть некая переменная типа *общий баланс* ( ну это и логично, что именно в этом модуле должна быть эта переменная ) . Рассматривая дальнейшую логику, нам оказывается требуется показать общий баланс например в модуле меню или в чате ( образно говоря ) . Однако, как уже было сказано вся логика денег - в денежном модуле.
Вопрос : имеем ли мы право объявить в денежном модуле переменную *общий баланс* статической, чтобы из любого другого модуля можно было получить ее, если понадобится?
Разговор идет именно о редких переменных, а не о каждой типа на всякий случай.
Если же такая логика считается избыточной, то как в данном случае должна выглядеть нормальная архитектура?

[Deimos747]

Как вариант, создать класс, в котором будут статические ссылки на каждый из модулей (если они конечно в единичных экземплярах).

[in4core]

Они в единичных это понятно. Но дело то не в том,
в котором будут статические ссылки на каждый из модулей
Чем ваш подход кардинально отличается от
SomeClass.someVar ? Зачем создавать еще класс чтобы хранить в них ссылки, если мне нужна всего лишь 1 переменная ? Вообщем я скорее спрашиваю, такая архитектура нормальна или нужно меньть подход?, но как?

[Zebestov]

Вот все ругают MVC, как "неуместную головомойку" при создании игр, а там как раз таких проблем не возникает. Не надо было бы никаких статиков. Просто всем заинтересованным видам/контроллерам выдается ссылка на некий PointsModel (можно ограничить интерфейсом), в котором есть, например, геттер totalPoints.

[botbot]

Вот все ругают MVC, как "неуместную головомойку" при создании игр, а там как раз таких проблем не возникает. Не надо было бы никаких статиков. Просто всем заинтересованным видам/контроллерам выдается ссылка на некий PointsModel (можно ограничить интерфейсом), в котором есть, например, геттер totalPoints.
Там есть более сложная задача - распилить модули на mvc. И я, честно говоря, так и не понял как это красиво сделать. Либо получается правильная но сложная структура, либо всё в общей каше. Для меня пожалуй это один из главных аргументов, почему я не пользуюсь mvc если не вижу крайней нужды.

[in4core]

Вот все ругают MVC, как "неуместную головомойку" при создании игр Тут скорее не важно игра это или еще что. Zebestov - не смог ли бы ты привести маленький пример решения моего вопроса через MVC или еще как?

[botbot]

Насчёт темы топика: я обычно вывожу подобные данные в один какой-то общий класс, который состоит из статических полей, которыми пользуются несколько модулей.
Но по конкретному примеру - скорее бы просто писал ссылку на модуль денег в модуле чата и меню.

[Zebestov]

MainModel содержит _pointsModel:PointsModel (есть геттер pointsModel)
Модули MainMenu и Chat получают ссылку на mainModel.pointsModel в конструктор, где она сохраняется в _pointsModel:PointsModel. После этого можно в любой момент взять _pointsModel.totalPoints.

[Silicium]

Вот все ругают MVC, как "неуместную головомойку"
и очень зря

[in4core]

Zebestov я тебя понял именно так :

MainModel.as

private static var _pointsModel:PointsModel = new PointsModel();

public function get points():PointsModel {...}

MainMenu.as

public function MainMenu() {
_point /*singleTone*/ = MainModel.getInstance();
_point.setNewPoint(***);
trace(_point.points(***)) // ok
}

так чтоли?

Добавлено через 4 минуты
Только вот если я правильно понял, то вариант trace(SomeClass.somePoint) будет в 100 раз понятнее и удобнее, чем твой подход, но если понял неверно, тогда хотелось бы подробнее

[ChuwY]

Возьму на себя ответственность сказать, что ты думаешь неверно.
Ув. товарищ Зебестов не использовал статики.

MainModel.as

private var _pointsModel:PointsModel = new PointsModel();

public function get points():PointsModel {...}

MainMenu.as

public function MainMenu(pointsModel : PointsModel) {
_point = pointsModel;
_point.setNewPoint(***);
trace(_point.points(***)) // ok
}

У контекста создания MainMenu, очевидно, уже была ссылка на PointsModel или же вообще на MainModel.

MainController.as

_mainModel : MainModel = new MainModel();
_mainMenuController : MainMenuController;
public function MainController(host : DisplayObjectContainer){
//...
_mainMenuController = new MainMenuController(_mainModel.pointsModel);
}

[in4core]

Ув. товарищ Зебестов не использовал статики. Статика тут не причем, она не меняет смысла архитектуры поста, ChuwY - ваш пример так же кардинально не отличается от того, что я понял, - итого считаю , что мой вариант будет лучше, если переменных таковых 3-5 , но будет менее функциональным если переменных 10-20 и т.д.

[Zebestov]

так чтоли?
Нет.
Зебестов не использовал статики
Совершенно верно.

Добавлено через 2 минуты
Статика тут не причем, она не меняет смысла архитектуры поста, ChuwY - ваш пример так же кардинально не отличается от того, что я понял
Статика тут неуместна.
Код ChuwY наглядно демонстрирует подход.

[artcraft]

тут подойдёт дизайн паттерн "провайдер"

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

[carrotoff]

Не люблю статику. Совершенно. Подход Zebestov лучше в разы, если смотреть в перспективу. На личном опыте напоролся на очень большой рефакторинг (точнее вынужден был применить), из-за завязки архитектуры на статические классы, которые как раз использовались как хранилища данных (что, собственно, пытаетесь сделать и вы). Кроме хэлперов и общедоступных констант статику лучше не использовать нигде

[fish_r]

Где то на форуме было обсуждение применения bindable в контексте флеша (не флекса), wvxvw правда критикует это дело и в той, и в другой среде :). Но поищИте, может это как раз то, что нужно.

[in4core]

carrotoff так собственно я и сказал, что при сложной архитектуре данный метод будет обоснован полностью, но при 2-3 переменных , не вижу смысла расписывать такую архитектуру. В любом случае я пришел суда узнать , как делают другие - узнал, очень рад этому.

[terbooter]

Я бы делал древовидную модель вместо статических свойств, даже если пока есть только пара-тройка общих свойств.
Напрмер, в приложениях для социалок у меня всегда есть такие классы листья модели: MeData - хранит деньги, очки и прочее, SocialData - профили юзеров в социалке, АррData - флэшвары, конфиги ...

Это самый "общий" уровень приложения. Те модули про которые вы говорите (модуль чата, денег и меню) будут скорее вьюшками в этом масштабе. Это и понятно. Например, чат будет брать из MeData собственное имя и статус, а из SocialData имена котрагентов. Меню, возможно, будет брать деньги из MeData чтобы дизэблить некоторые элементы. А из АррData будет брать список дополнительных пуктов
Сами модули, являясь вьюшкой для крупного масштаба, тоже могут иметь мвц структуру.
Например, список с пагинатором.

[Zebestov]

...при сложной архитектуре данный метод будет обоснован полностью, но при 2-3 переменных, не вижу смысла расписывать такую архитектуру.
Недальновидно.

[in4core]

Недальновидно. Опять же ДА, если не уверен, что может все поменяться. В данном случае, я уверен, что больше 2х не будет :)

[carrotoff]

Нет, это недальновидно, без всяких "если". Не нужно обманывать самого себя

[Zebestov]

...я уверен...
Уверенности не место в программировании. Ее следует в спешном порядке заменить на предусмотрительность.
Не изгнали бы уверенность — жили бы сейчас без инкапсуляции, например.

[dimarik]

поделена на модули

Замените слово "модуль" на "класс" и жить будет легче.

[Psycho Tiger]

Мне всегда так нравится!
- Ребята, я вот делаю так, это правильно?
- Нет, это совершенно не правильно, неудобно и недальновидно.
- Эээ... Да, это так! Но я всё-равно буду делать по-своему!