Просмотр полной версии : MVC: грамотная архитектура проекта
elder_Nosferatu
30.09.2013, 17:29
Салют!
Я однажды познакомился с идеей MVC (спасибо Тигре). Тогда все казалось удобным и правильным. Но все мои упражнения в этом направлении ничего хорошего не принесли. Каждый раз модель превращалась в обычный VO, а вся логика делилась межуд видом и контроллером. Метод не самый плохой - мне удавалось сосредоточить данные в одном месте, где их могли подхватить все заинтересованные виды, но от MVC почти ничего не осталось.
Не так давно у одного блогера я вычитал утверждение, о том, что если в проекте нельзя вырезать вид и заменить его новым, без каких либо изменений в остальном проекте, тогда архитектура, скажем так, не прошла "MVC-проверку". Это он объяснил на примере игры-шутера: Если у Вас есть грамотно написаный шутер с изометрическим видом (скажем, как у Alien Shooter), тогда просто переписав вид можно сделать из него 3D-шутер (как Wolfenstein 3D). Я пришел к выводу, что теоретически в такую игру можно играть даже без вида - действия игрока передаются в модель через контроллер и в самой модели уже происходит "экшн", а вьюшки нет, значит просто некому это отобразить.
После этого я еще раз понял, что мое стремление сделать из моделей просто "говорящие" VO не совсем соответствует парадигме MVC и я в очередной раз решил создать проект с "правильным MVC". Думал-думал и придумал себе проблему: калькулятор то написать в таком стиле не проблема, а тот же шутер - не так просто...
Вот Вам ситуация: непрерывная стрельба. Если речь идет о скоростреле, тогда все просто. Кто там успеет посчитать все пули... Модель просто будет генерировать снаряды через определенное количество времени и считать их попадание + урон. А в это время вид будет отображать какое нибудь подергивание оружия да вспишки выстрелов, ну возможно будет еще полоска, имитирующая полет очереди пуль. Попробуй придраться - все выглядит естественно. А теперь меняем свой чудо-автомат на помповое ружье и... Конец халяве! Выстрелы на столько редкие, что так халтурить при их отображении уже не получится :(
Лично я вижу два варианты реализации, но мне они не очень нравятся...
1) Модель знает сколько должен длится выстрел и ей плевать на вид. А вид получает уведомление о выстреле и начинает анимацию вистрела, отдачи, перезарядки, возвращения в исхоное положение. Все круто, но во время сильной нагрузки плеера (в браузере, кроме игры, запущено еще 4 сериала и две социалки с тонной векторной графики и фильтров) звук этого набора действий проиграется без проблем и, скорее всего, синхронно с моделью , а анимация скорее всего будет хромать.
2) Модель делает выстрел и ждет указаний контроллера для следующего выстрела. А контроллер, в свою очередь, ждет известий от вида, что выстрел благополучно закончен и только тогда командует модели "Пли!". Вариант очень красивый, но тогда получается, что модель очень сильно зависит не только от действий игрока, но и от действий вида. К тому же такой подход порождает множество "висячих макаронин" - дыхание модели разбито на вдох/выдох и без разрешения вида, посланное через контроллер, хоть умри, но дишать нельзя. Хотя нет, чтобы умереть тоже нужно разрешение.
О как наворотил... Но и это не самая сложная ситуация. В обоих реализациях либо модель либо вид решают сколько должно длиться конкретное действие. А что, если от их воли ничего не зависит. А что, если такое решение принимает сервер - пойди узнай, когда он ответ пришлет. И это все сгенерировала моя скудная фантазия, а что подкинет реальная практика? Бррр...
Короче, если заглянет сюда какой нибуть поклонник MVC, очень прошу укажите мне на мои ошибки в рассуждениях и дайте несколько рекомендаций, в каком направлении стоит двигаться. Ато казалось бы парадигма MVC должна упростить какие нибудь аспекты разработки, но "Мое MVC" только создает проблемы на пустом месте.
AlexCooper
30.09.2013, 17:54
elder_Nosferatu есть еще различные подвиды MVC. Я лично использую архитектуру где
Модель - "хранилище данных" и "методы поведения" данной модели
Контроллер - создает модели и вьюверы, основная работа связывание активностей между моделями и вьюверами.
Вьювер - получает модель и отображает её
В таком случае, я бы написал следующее.
Контроллер вызывает в модели метод Выстрел из точки А в точку В ракетой.
Модель генерирует событие - "выстрел" и записывает в массив "летящие_снаряды" характеристики данного выстрела ( точка А,Б, тип оружия, скорость движения)
Вьювер получив от модели событие выстрел, получает массив снарядов, по надобности добавляем проверку что-бы не отображать одни и те же снаряды несколько раз, соответсвено получает характеристики этого снаряда и отображает полёт.
Блогер, вообщем-то, всё верно написал.
В моделе, вам необходимо описать 2 разных типа оружия. Оба оружия должны наследовать абстрактный базовый класс всех орудий, например - AGun. В базовом классе - есть методы, необходимые всем орудиям, но конкретную реализацию определяет конкретный наследуемый класс.
В базовом классе, вы добавите курок - onFire. В наследуемом классе, этот "курок" Может автоматически переходить в положение false после выстрела, или ждать внешнюю команду "отжатия" - в зависимости от типа оружия. Соответственно, модель игры ведёт огонь, если курок нажат, и не ведёт, если он отжат.
Всем этим заправляет модель, задача контроллера лишь - дёргать этот курок. Контроллер не должен описывать сам процесс выстрела, эта элементарная задача лежит на моделе. Вообще, все элементарные задачи, должна решать сама модель. Такие как: перемещение физического тела юнита в мире, перезарядка оружия, нанесение урона объекту, если в него попала пуля.. Задача контроллера - более глобальная, он выдаёт приказы, управляет действиями ИИ: юнитА -> переместиться в точку B, юнитБ -> вести огонь по противнику. А элементарное выполнение приказа - лежит на моделе. Ей решать, как конкретный тип юнита будет выполнять этот приказ.
Что-бы легче понять, представьте себе, что модель - это описание мира со всеми его законами. Модель описывает гравитацию, и она же её применяет ко всем объектам в мире. Контроллер же - лишь манипулирует этим миром, создаёт новые объекты, указывает объектам, что они должны сделать. Но как именно это сделают объекты - это решает модель, в соответствий с её законами. Если объект падает в лаву - модель без чьего-либо разрешения - уничтожает этот объект. Ведь в соответствий с её законами, объекты не имеющие флаг "read-only" - уничтожаются в лаве. И конечно, модель высылает событие уведомления о печальной участи объекта.
В визуализаторе архитектура построения отображения - идентична модели. Во вью есть абстрактный базовый класс для всех орудий - AViewGun, все наследуемые классы, самостоятельно определяют, как им отображать их тип оружия.
Как может выглядеть ситуация с выстрелом из дробовика:
Любое оружие в игре, (AGun) имеет курок: onFire (курок нажат/нет). Конкретный класс дробовика, наследует AGun. Далее, дробовик при каждом шаге игры сам проверяет - если его перезарядка выполнена (оружие может выстрелить) и нажат его курок - он стреляет, устанавливая затем новую паузу перезарядки. Внешний код - может 500 раз нажать на курок, но сам выстрел произведёт только дробовик, когда его удовлетворят все условия.
Akopalipsis
30.09.2013, 18:05
AlexCooper Вы обошли стороной вопрос автора. Если следовать Вашей логике, то имея в руках автомат и нажав пять раз кнопку, вью передаст контроллеру пять кликов, тот передаст модели пять кликов, модель рассчитает сколько пуль выпущено за каждый клик и передаст пять массивов во вью. И все работает, так же как и сказал автор, но если такой подход применить к дробашу, то когда пользователь так же нажмёт пять раз, то модель получит пять массивов с редкими выстрелами дробаша.
Но а вдруг пользователь судорожный и пока один выстрел не закончил нажал ещё сто раз и побежал, то получится, что пока он бежит дробаш будет стрелять.
AlexCooper
30.09.2013, 18:15
Akopalipsis как написал товарищ Tails, модель это всё обрабатывает, стрелять или нет решает она.
Akopalipsis
30.09.2013, 18:29
Оффтоп - вчера сделал виток в обучении в сторону этого шаблона и точно так же со вчерашнего дня не могу решить одну проблему. модель не чего не говорит контроллеру, который имеет связь с сервисом. как модель может сказать сервису, что ей нужно больше данных?
AlexCooper
30.09.2013, 18:36
Akopalipsis модель диспатчит событие "хочу_жрать", контроллер ловит это событие ( естественно преждевременно подписавшись) и отдает данные от сервиса в модель.
Akopalipsis
30.09.2013, 19:03
модель диспатчит событие
Кому?
Добавлено через 12 минут
AlexCooper Вы не сочтите мой короткий вопрос - "Кому", за дурной тон. Просто мне уже раз обьясниле, что если контроллер подписан на модель это не mvc..
elder_Nosferatu
30.09.2013, 19:23
@Tails
Судя по Вашему примеру с дробовиком, Вы вообще отвергаете мой 2-рой вариант реализации выстрела (модель заявляет о начале выстрела и ожидает известия от контроллера, что вид закончил отображение выстрела). По моему этот вариант дает возможность синхронизировать поведение модели с отображением этого поведения, Но все же меня просто бесит то, что модель ждет разрешения на продолжение деятельности от вида. К тому же такой подход сильно прибавляет в коде: модель расказала виду, он некоторое время это отображает и докладывает контроллеру о завершении, а ток уже командует модели "давай, расказывай дальше". Каждый набор последовательных действий порождает целый вихрь из евентов... Даже если бы это был ТРУ-МВЦ, я бы не стал так делать - просто заворот мозгов!
Но все же меня не покидает мысль о том, что может возникнуть ситуация, когда последнее слово будет за видом...
AlexCooper
30.09.2013, 19:25
Akopalipsis Из материалов википедии
Начинающие программисты (особенно в веб-программировании, где аббревиатура MVC стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC. В этом случае модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику. В результате код моделей по факту является средством получения данных из СУБД, а контроллер представляет собой типичный модуль, наполненный бизнес-логикой, или скрипт в терминологии веб-программирования. В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)[6]:
Среднестатистический ТТУК получал данные из БД (используя уровень абстракции базы данных, делая вид, что это модель) или манипулировал, проверял, записывал, а также передавал данные в вид. Такой подход стал очень популярен потому, что использование таких контроллеров похоже на классическую практику использования отдельного php-файла для каждой страницы приложения.
Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, а вся бизнес-логика. В свою очередь, контроллеры представляют собой лишь элементы системы, в чьи непосредственные обязанности входит приём данных из запроса и передача их другим элементам системы. Только в этом случае контроллер становится «тонким» и выполняет исключительно функцию связующего звена (glue layer) между отдельными компонентами системы.
А кому оно еще может диспатчить событие? Контроллер вешает слушатель на модель и при срабатывании передает запрос сервису.
Добавлено через 1 минуту
elder_Nosferatu модель никого никогда не ждёт. Она живёт своей жизнью.
http://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/MVC-Process.png/200px-MVC-Process.png
Akopalipsis
30.09.2013, 19:29
контроллер слушает модель?) Он может быть подписан на события в модели?
Может. Но идею это нарушит.
И эти слова не опроверг не один участник, который высказывался после..
Кому верить?
Добавлено через 37 секунд
А про эту статью я сто раз читал, что она вроде как не правильная...
Добавлено через 7 минут
AlexCooper если Вы наберётесь силы и прочтете статью, то увидете, что Ваши слова отвергают на протяжении всей темы.
AlexCooper
30.09.2013, 19:46
Akopalipsis какую статью?
Akopalipsis, для начала скажите, к какому из фигурантов MVC относится сервис?
Akopalipsis
30.09.2013, 20:02
для начала скажите, к какому из фигурантов MVC относится сервис?
После дня ожидания и поисков в надежде найти правильный ответ, я пытался ответить сам. И выходит вот что - сервис нужен модели, а значит создавая сервис, контроллер должен передать в его конструктор ссылку на модель. А в самом сервисе тип у модели должен быть IModel, так как модели меняются, а сервиса это касаться не должно. я правильно понимаю?
какую статью?
Вот от сюда хотя бы http://www.flasher.ru/forum/showthread.php?t=138349&page=53
@Tails
Судя по Вашему примеру с дробовиком, Вы вообще отвергаете мой 2-рой вариант реализации выстрела (модель заявляет о начале выстрела и ожидает известия от контроллера, что вид закончил отображение выстрела). По моему этот вариант дает возможность синхронизировать поведение модели с отображением этого поведения, Но все же меня просто бесит то, что модель ждет разрешения на продолжение деятельности от вида. К тому же такой подход сильно прибавляет в коде: модель расказала виду, он некоторое время это отображает и докладывает контроллеру о завершении, а ток уже командует модели "давай, расказывай дальше". Каждый набор последовательных действий порождает целый вихрь из евентов... Даже если бы это был ТРУ-МВЦ, я бы не стал так делать - просто заворот мозгов!
Конечно вас это бесит, потому-что это вообще "чёрт знает что", как вы до такого только додумались.. Зачем модель должна что-то там синхронизировать с вью? Модель работает сама по себе, она ничего абсолютно не должна знать про то, кто её, как и где нарисует.
Но все же меня не покидает мысль о том, что может возникнуть ситуация, когда последнее слово будет за видом...
Такой ситуаций не может быть в принципе.
В правильном MVC - в игру можно играть вообще без визуализатора. Визуализатор - это лишь порт вывода данных игры игроку. Красивый и разноцветный, со свистелками и перделками - но никак не влияющий на игровой процесс. Визуализатор живёт своей жизнью, он рисует модель игры так, как ему хочется.
В визуализатор может помещаться слушатель пользовательского ввода, который будет регестрировать клики мышкой, ввод с клавиатуры и прочие действия игрока. Затем, слушатель их минимально обрабатывает - (нажата кнопка включения двигателя, нажата кнопка стрельбы) Эти данные считываются контроллером и уже он принимает какие-то конкретные действия. Слушатель помещается во вью только потому, что от-туда ближе всего доступ к устройствам ввода.
Кому?
Добавлено через 12 минут
AlexCooper Вы не сочтите мой короткий вопрос - "Кому", за дурной тон. Просто мне уже раз обьясниле, что если контроллер подписан на модель это не mvc..
Не совсем так. Модель - потому и диспетчер, что её события могут понадобиться кому угодно. Вполне возможна ситуация, когда некоторый контроллер будет подписан на какие-то события модели. Например, второстипенный под-контроллер, может активироваться по наступлению какого-то события в игровом мире - "случилось извержение вулкана - запускается спаунер огненных мобов.", игрок погиб - оживает главный контроллер, завершает игру, открывает меню.
Если более обширный пример - то система игровых триггеров. Игровой триггер - это некоторое действие (контроллер) который активируется по наступлению некоторого события в игре (подписан на модель)
elder_Nosferatu
30.09.2013, 21:08
Я тут придумал ситуацию которая сможет меня заставить поламать свой "правильный MVC". Надеюсь знатоки подскжут, как этого избежать.
Итак, предположим, что у нас есть ТаверДефенс. Каждой башне присваивается трофей за убиение противника (скальп, уши, зубы). В конце уровня все трофеи обналичиваются. Происходить это должно так: открывается окно, в котором все задействованые башни строятся в ряд, а перед ними ставится сундук с казной. Далее с каждой башни по очереди сыпится в сундук столько монет, сколько стоят ее трофеи, а потом звучит какая нибуть фраза типа "Гуд джоб!", "Вел доне!" или "Ух, блоод моней...". Когда все башны подоены появляется кнопка закрытия окна.
Лично мне на ум приходит умная самостоятельная вьюшка, которая принимает от модели текущее количество денег в казне и массив, с количеством элементов, равным количеству башен и каждый элемент обозначает количество заработаных башней денег. Таким образом модель занимается только важной работой (наблюдает за башнями и во время обналички трофеев расказывает кто сколько заработал). Что вид будет делать с этими данными ее не колышет. А вид действует по своему сценарию - сгребает монеты с башни и благодарит ее фразй, потом переходит к следующей. Завтра я передумаю и буду сгребать монеты со всех башен одновременно и это никак не отобразится на модели. Зато модель не знает сколько вся эта сценка должна длиться. И даже если посчитать сколько времени уйдет на сгребание всех монет, то все равно модели не извесно сколько длится звучание благодарственной фразы. По этому ей прийдется глубоко вдохнуть и ждать разрешения выдохнуть кнопку закрытия окна.
В результате мы имеем изящную, но зависимую модель и умный вид, который может легко и без вреда для окружающих менять свое поведение.
Если же следовать заветам MVC и делать модельку самостоятельной, тогда для реализации данной идеи ей прийдется обзавестись таймером; сделать себе шпаргалку с длительностью звуков благодарения; расчитать положение башен и сундука; расчитывать движение монеток от каждой башни к сундуку; решать каой же фразой поблагодарить солдат из башни за проделаную работу; требовать, чтобы кто нибуть произнес эту фразу, а самой в это время ждать с секундомером в руках, пока фраза будет произнесена (в надеже, что ее вообще хоть кто нибудь взялся озвучить). По завершению всех этих епилептических подергиваний модель, с чувством выполненого долга сможет потребовать кнопку закрытия окна. Печальная картина... Но зато теперь претензии к вьюшке минимальны. Ей вообще теперь не о чем думать - расказывай, что от модели услышала и все дела. Даже начального образования не нужно...
И на счет изменения в сценарии получения денег, теперь нам однозначно прийдется менять модель, а добавляя новые фичи получаем необходимость и вьюху кромсать.
А теперь очень жду, что мне подскажут, почему мой MVC такой некрасивый, а если он у вссех такой, то почему от него так тащатся?
Если же следовать заветам MVC и делать модельку самостоятельной, тогда для реализации данной идеи ей прийдется обзавестись таймером; сделать себе шпаргалку с длительностью звуков благодарения; расчитать положение башен и сундука; расчитывать движение монеток от каждой башни к сундуку; решать каой же фразой поблагодарить солдат из башни за проделаную работу; требовать, чтобы кто нибуть произнес эту фразу, а самой в это время ждать с секундомером в руках, пока фраза будет произнесена (в надеже, что ее вообще хоть кто нибудь взялся озвучить). По завершению всех этих епилептических подергиваний модель, с чувством выполненого долга сможет потребовать кнопку закрытия окна. Печальная картина... Но зато теперь претензии к вьюшке минимальны. Ей вообще теперь не о чем думать - расказывай, что от модели услышала и все дела. Даже начального образования не нужно...
И на счет изменения в сценарии получения денег, теперь нам однозначно прийдется менять модель, а добавляя новые фичи получаем необходимость и вьюху кромсать.
Вот до этого абзаца вы рассуждали верно. Вам не нужно засовывать ваши "экраны меню" в модель. Экраны меню - задача исключительно визуализатора. Модель должна лишь предоставлять все необходимые данные: очки, данные вышек, заработанный профит.. Как долго воспроизводить анимаций/звуки и когда игроку показать кнопку "выход" - решает только вьюшка.
Akopalipsis
30.09.2013, 21:25
Как долго воспроизводить анимаций/звуки и когда игроку показать кнопку "выход" - решает только вьюшка.
Вот у меня опять складывается впечатление, что я вообще не понимаю. Как это вью сама решает, если она не чего не решает? Возможно клик по кнопке передастся через контроллер в модель, которая и будет решать ,конец это или ещё жизни остались. И если опять таки модель не будет знать о длительности анимации дробаша, то как она поймет что уже нужно второй выстрел диспатчить? Тут тогда получается, что массив выстрелов должен быть во вью, которая будет считать что уже можно второй выстрел...
Wolsh ?
Да, нужно уточнить:
В данном примере, мы имеем окошко вьюшки - отображающее статистику пройденного уровня. Это окошко - диспетчер, которое изначально имеет 1 событие - [EventExit]. На это событие подписан контроллер, который ожидает его от окошка.
Получается такая схема: Игра заканчивается, запускается окошко статистики, которое зараза, сразу не показывает кнопку выход! Оно насильно отобразит вам анимацию, проиграет 15 звуков и только после этого появиться кнопка выхода, нажав на которую, вышлется событие [EventExit] и внешний контроллер продолжит выполнение.
Таким образом, в своей локальной зоне - вьюшка сама решает, когда ей показать кнопку, как выслать событие [EventExit] (нажав на кнопку, подождав всю анимацию или т.п.) и выслать ли вообще.
И если опять таки модель не будет знать о длительности анимации дробаша, то как она поймет что уже нужно второй выстрел диспатчить?
Дробовик перезаряжается не через анимацию же! У дробовика модели есть переменная - recharge, которая указывает, сколько ещё времени нужно дробовику, что-бы тот перезарядился. Дробовик в моделе выстрелил - вью словила эвент и нарисовала огонь. Что тут не понятного?
Akopalipsis
30.09.2013, 21:52
Тогда получается так: юзер убивает последнего монстра и модель узнает из внутреннего события об окончании монстров в хранилище. Она шлет событие "конец". Вью его ловит и проигрывает анимацию о длительности которой модель не обязана знать. Внутри вью как не крути логика есть все равно, но своя внутри-вьшная, считать кол-во частиц, начало конец анимации и т.д. Но её события на все приложение роли не какой не оказывают, даже по окончанию анимации и после принятия внутреннего решения о показе кнопки, при клике она шлёт событие передаваемое контроллером в модель. И модель уже решает - перехожу в главное меню. И это нормально. Но у меня после прочтения вопроса ТС до сих пор остался вопрос без ответа - почему в описанном мной случаи уведомление от вью модели - это нормально, а уведомление, когда модель не знает о времени воспроизведения анимации выстрела - это не нормально...?
elder_Nosferatu
30.09.2013, 21:54
@Tails
Столько написал, что даже смогу более конкретно описать проблему.
Получается, что если длительность какого либо действия зависит от длительности анимации или звука, тогда это значение нужно записать в модель, как параметр и просто засекать нужное время в тот момент когда виду подается команда на отображение/озвучку. Но тогда нужно полностью отказаться от родной покадровой анимации. В случае тормозов длительность кадра/кадров может сильно увеличится, но таймеру на это плевать. Значит анимацию нужно прокручивать вручную с расчетом прошедшего времени. Я правильно понял?
Такое ощущение, что Вы книжку (или что там) начали читать с пятого параграфа.
Модель создает, хранит, обрабатывает и отдает ДАННЫЕ.
Вью обеспечивает физический ИНТЕРФЕЙС с пользователем.
Контроллер обеспечивает программный интерфейс между Вью и Моделью.
Akopalipsis, Ваши трудности происходят из смешения двух противоречащих концепций, MVP и MVC. Вы цитируете взятое из MVC поведение тонкого контроллера, но при этом продолжаете мыслить контроллер как средоточие логики и класс, который всем заправляет. "Создавая сервис, контроллер должен..." — нафига контроллеру сервис? Вы покупаете кабель и к нему компьютер, или как? Контроллер принадлежит сервису. Он ЕГО контроллер. И это контроллер, не имеющий никакого отношения к контроллеру из MVC. Это личный склад Модели. Отношения Модели и сервиса не входят в парадигму MVC. Вы можете найти какие-то параллели, конечно, представить Модель как Вью для сервиса, или наоборот сервис как этакий Вью, поскольку от него что-то поступает и, если постораться, то через отдельный контроллер.. Но Модель не Вью. И сервис не Вью. MVC просто О ДРУГОМ. Никто же никогда не говорил, что MVC описывает ВСЁ приложение в деталях, каждое отношение во всей программе. От таких мыслей Вы дойдете до того, что "контроллер создает Модель и Вью" и прочей ереси, неизбежной, когда "есть только контроллер, вью и модель". Они все независимы. В этом парадигма MVC. Никто из них не может создавать другого, это приведет к жесткой связанности через импортирование конкретного класса.
elder_Nosferatu
30.09.2013, 22:12
К сожалению, ничего дельного по MVC еще не читал. Я просто ярый перестраховщик/универсализатор/рационализатор/оптимизатор. Иногда могу себя в такие дебри загнать, что... Уже не раз ловил себя на мысли, что к своему универсальному инициализатору я собираюсь писать инициализатор :( И слава богу, если к нему не прийдется такой же писать.
Метания с дробовиком я, если честно, вообще не понял.
Он стреляет когда?
Откуда эта идея, что "стреляет модель"? Стреляет юзер! После выстрела дробовик перезаряжается (во вью) и юзер НЕ МОЖЕТ выстрелить в этот момент. Какая разница, сколько времени длится перезарядка? Юзер сможет снова выстрелить, только когда она закончится. Так при чем тут модель? С какого перепугу она-то должна стрелять, пока юзер не нажал "выстрел"? А он не может нажать, пока идет перезарядка. Модели даже знать не надо таких параметров как скорострельность и т.п., она просто получает от контроллера "юзер нажал выстрел" и считает последствия, меняет кол-во патронов в обойме и считает нанесенный ущерб. Это ДАННЫЕ. А остальное — забота вьюхи. Да. "Может ли вот сейчас выстрелить дробовик" это забота вьюхи. Все что ей надо для этого от модели — это кол-во патронов.
Что я думаю не так?
Akopalipsis,
Тогда получается так: юзер убивает последнего монстра и модель узнает из внутреннего события об окончании монстров в хранилище. Она шлет событие "конец".
Модель ничего не должна определять, она сухо указывает, что убит монстр, осталось - 0.
Контроллер решает, что 0 монстров - это "конец" и заканчивает игру в модели (модель высылает событие завершения)
Тут вью тихо ловит событие завершения - выгружает свой визуализатор уровня.
Контроллер открывает главное меню во вьювере на прямую и работает с ним. Модель не должна содержать информаций о текущем экране меню, если в этом нет непосредственной необходимости. (Момент вполне может показаться спорным, но к такому выводу я однажды пришёл и готов подискутировать на эту тему)
Tails, Вы только сбиваете Akopalipsisа своим толстым контроллером. Да и топик-стартера тоже (он же в самом начале писал о том, что работает именно над схемой с тонким контроллером).
Ваш второй пункт можно смело засунуть в первый: Модель решает, что 0 монстров - это "конец" и заканчивает игру в модели (модель высылает событие завершения).
Про меню (п4) мне лично тоже интересно. Я пытался как-то сделать через "модель состояний" внутри модели, но получалось очень криво, аж медиаторы начали выглядывать из-за деревьев и призывно махать ручками, а я их очень не хотел.
Psycho Tiger
30.09.2013, 22:36
Я тут мимо проходил и сильно тему не читал – не осилил.
Хочу накинуть такую тему: стреляли по кружочкам, а потом геймдизайнер сказал – вместо кружков воткнуть параллелограмм! Проблемы нет, только придётся менять как модель, так и вью.
Я за то, чтобы не болеть фанатизмом: в примере стрельбы по кружкам вью вполне себе сама может определить попал-не попал.
Akopalipsis
30.09.2013, 22:49
В общем я пришёл к выводу, что пора уже открыть книгу и почитать. Открыл, читаю, могу сказать так - что пока не дочитаю не буду вообще на эту тему рассуждать...
Wolsh Вам огромное Спасибо! ТС - обязательно читайте книгу. Там вообще всё не как я до этого на форуме читал...
KumoKairo
30.09.2013, 23:09
Akopalipsis, по MVC в AS3 советую прочитать в этой книжке (http://shop.oreilly.com/product/9780596528461.do)
Полностью поддерживаю (правда читал на русском)).
Akopalipsis
30.09.2013, 23:19
KumoKairo Спасибо! я её как раз и читаю, мне очень нравится стиль, которым описывают все шаблоны.
@Tails
Столько написал, что даже смогу более конкретно описать проблему.
Получается, что если длительность какого либо действия зависит от длительности анимации или звука, тогда это значение нужно записать в модель, как параметр и просто засекать нужное время в тот момент когда виду подается команда на отображение/озвучку. Но тогда нужно полностью отказаться от родной покадровой анимации. В случае тормозов длительность кадра/кадров может сильно увеличится, но таймеру на это плевать. Значит анимацию нужно прокручивать вручную с расчетом прошедшего времени. Я правильно понял?
В конечном счёте, применяемая методика зависит от целей конкретной задачи. Нет решения, которое бы подошло в 100% случаях всем.
Конечно, для мп3 плеера, отдельно задавать время воспроизведения трека было-бы не разумно, гораздо выгоднее прослушивать сам мультимедиа файл. Этим мог-бы бы занимался соответствующий контроллер.
Для анимационного окна интерфейса в игре, хорошим решением будет предоставление ему управляющих событий, которые оно могло бы использовать, информируя внешний код о тех или иных действиях пользователя. В этом случае, контроллер подписанный на это окно, будет принимать дальнейшие решения.
Для игрового процесса, все действия должны быть описаны в моделе: перезарядка, регенерация, всё это - относиться к логике игрового процесса и просто не может быть завязано на каких-то там анимациях. В этих случаях, анимация подстраивается под модель, а не наоборот.
После выстрела дробовик перезаряжается (во вью) и юзер НЕ МОЖЕТ выстрелить в этот момент. Какая разница, сколько времени длится перезарядка? Юзер сможет снова выстрелить, только когда она закончится. Так при чем тут модель? С какого перепугу она-то должна стрелять, пока юзер не нажал "выстрел"? А он не может нажать, пока идет перезарядка. Модели даже знать не надо таких параметров как скорострельность и т.п., она просто получает от контроллера "юзер нажал выстрел" и считает последствия, меняет кол-во патронов в обойме и считает нанесенный ущерб. Это ДАННЫЕ. А остальное — забота вьюхи. Да. "Может ли вот сейчас выстрелить дробовик" это забота вьюхи. Все что ей надо для этого от модели — это кол-во патронов.
Что я думаю не так?
Таким образом, вы с успехом засовываете всю логику и половину модели дробовика во вью. Мало того, у вас дробовик, игрок и управление - это "один монолитный блок". Да это работает, для очень простого примера. Но проблема в том, что как только вам понадобиться внести чуть более широкий функционал, вам таки придётся разделить логику, отображение и данные на отдельные составляющие.
Кто ещё из нас советует "толстый контроллер" ?
Таким образом, вы с успехом засовываете всю логику и половину модели дробовика во вьюЭто очень важный вопрос — что является логикой. Посылать ли событие "выстрел", если юзер нажал клавишу в момент перезарядки оружия — это логика? Его нажатие НИЧЕГО НЕ МЕНЯЕТ в игре. Данные Модели здесь никоим образом не должны изменяться. Никакого события нет. Никакой "логики" на уровне Модели здесь не требуется.
"Засунуть всю логику" было бы рассчитать полет пули и ее попадание в противника прямо во Вью (где есть все координаты), а для Модели посылать только событие "враг получил пулю, проверьте как он там".
"Вытащить всю логику" означает каждый пиксель полета пули брать из Модели, и каждый кадр предсмертных судорог, и каждый кадр процесса перезарядки (ну, а что еще такое "таймер в модели", по-вашему?) Вам то не кажется, что Вы пихаете Вью в Модель?
Весь вопрос стоит на том, что именно считать данными. Есть ли какие-то данные в том, что юзер нажал курок во время перезарядки? Зачем это Модели? Это вопрос чисто интерфейса игры с пользователем. Зачем Модели подтверждать выстрел? Вью не справится с тем, стрелять или нет, на основании данных (из Модели!) о количестве патронов в обойме и текущего состояния анимации дробовика? (готов к выстрелу/не готов)? Зачем конкретно Модели знать, готов к выстрелу дробовик или нет? На какие данные/логику это может повлиять, кроме как "реагировать на событие ЮзерНажал, или нет, если вдруг это событие придет"? Так вот придет ли событие, это вопрос интерфейса, то есть Вью.
Добавлено через 35 минут
вам таки придётся разделить логику, отображение и данные на отдельные составляющиеПростите, но ЛОГИКА не может существовать без ДАННЫХ. Держать логику в контроллере означает сделать из Модели гулящую девку, готовую отдавать все что попросят, а не только нужные для отображения конечные результаты(!) вычислений; означает обеспечить связку контроллер-модель сотней геттеров или проще уж тупо делать все её данные публичными. Это ООП?
Контроллер является ключевой фигурой в парадигме MVC. Вот только не потому, что является мозгом приложения. А потому, что именно он обеспечивает суть концепции MVC — разделение данных и отображения. Не будь контроллера, мы бы писали модель для конкретной вью и вью для конкретной модели. Только и всего. Контроллер призван собрать в себе всю эту конкретику. Он знает язык Вью и знает язык Модели. И "язык" здесь не просто как перевести слово. Он переводит СМЫСЛ, потому что смыслы для Вью и для Модели разные. Контроллер должен понимать смысл событий Вью для Модели. Иначе все вью будут вынуждены изначально писаться для этой конкретной модели, а модель — понимать, что ей делать при "юзер нажал клавишу Р".
Да, наш с вами разговор ни к чему не приведёт, пока мы обсуждаем реализацию некоторой абстрактной, не оговорённой конкретно задачи. Вы представляете её по своему, я по своему. Меня только задело, что вы не сильно придерживаетесь концепций MVC (как мне показалось):
Перезарядка дробовика - на мой взгляд, это несомненно логика.
Скорострельность - тоже логика.
И даже количество патронов в обойме это - логика, относящаяся к под-модели оружия.
Перенос и просчёт этих параметров в виде - слишком уж грубое нарушение концепций MVC (в моём представлений задачи). Возможно, вы представляли себе нечто иное и потому допустили такое перемешивание.
Как-бы там ни было, я читал книжки и с пятого и с десятого параграфа. Но основные советы и доводы которые приводил - были получены мною из личного, практического опыта. Конечно могу в чём-то ошибаться, поправьте. Автору бы я посоветовал прислушаться ко всем, но выводы сделать самостоятельно.
Простите, но ЛОГИКА не может существовать без ДАННЫХ. Держать логику в контроллере означает сделать из Модели гулящую девку
Верно. Под логикой - я имел ввиду контроллер верхнего уровня. Поясню:
В одном из сообщений в начале, я описывал, как модель (М) - вполне имеет внутреннюю логику, описывающую её базовое поведение, или "правила игры", или "общие законы игры". Сюда входят все просчёты столкновений, нанесение урона, лечение, перезарядка дробовиков и все прочие общие элементы.
Контроллер верхнего уровня (С) - занимается тем, что влияет на эту модель. Он помещает туда новые дробовики, нажимает курки, добавляет мобов.
пс. При этом, никаких толстых контроллеров или классов с сотней-две свойств - не наблюдается. Каждый элемент, будь то модель дробовика, контроллер игрока, модель игрока - работает только в своей области юрисдикции. Каждый элемент - выполняет строго отведённую ему задачу. На деле это окола 200 - 300 строк кода на класс.
Контроллер должен понимать смысл событий Вью для Модели. Иначе все вью будут вынуждены изначально писаться для этой конкретной модели, а модель — понимать, что ей делать при "юзер нажал клавишу Р".
В визуализатор может помещаться слушатель пользовательского ввода, который будет регестрировать клики мышкой, ввод с клавиатуры и прочие действия игрока. Затем, слушатель их минимально обрабатывает - (нажата кнопка включения двигателя, нажата кнопка стрельбы) Эти данные считываются контроллером и уже он принимает какие-то конкретные действия. Слушатель помещается во вью только потому, что от-туда ближе всего доступ к устройствам ввода.
реализацию некоторой абстрактной, не оговорённой конкретно задачиМне казалось, вопрос вполне понятен. Возможно, я все упрощаю, конечно.
Перезарядка дробовика - на мой взгляд, это несомненно логика.Это изменение данных о количестве патронов в дробовике и в рюкзаке. Эти числовые данные (даже не логика, уж простите) нужны для сейва, для отображения в HUD и окнах инвентаря и торговли. Состояние дробовика (я ведь правильно понимаю, что под "перезарядка дробовика" Вы имеете в виду временное состояние, когда стрелять из него нельзя?) нужно только для определения, будет ли иметь место событие "выстрел", когда юзер нажмет клавишу. Тут ровно ноль данных для Модели, это данные исключительно для интерфейса. Если очень хочется, Вы конечно можете хранить эти "данные" в модели и посылать события "дробовик начал перезарядку", "юзер нажал", "юзер снова нажал", "дробовик закончил перезарядку". Прикол в том, что, пошлете Вы эти события и будете хранить и менять состояние дробовика в Модели, или нет — в игре ничего не изменится. Это логика интерфейса на том же уровне, как "может двигаться ползунок слайдера дальше по х или нет". Ваш вариант — послать в модель события "ползунок достиг максимального значения", "юзер пытается двигать ползунок", "юзер всеравно пытается двигать ползунок", "о, перестал". Мой — посылать в Модель события "значение слайдера изменилось. новое значение 15%". Сравните, где есть информация, интересная для Модели.
Скорострельность - тоже логикаКак параметр оружия это — данные. Данные для логики? Например, да — для функции сравнения в инвентаре и торговле. Ой, кажется сравнение интересно только юзеру, а в Модели никаких данных не меняет? Чисто подсветить, выделить. У одной вью это есть, у другой нет, ибо только отвлекает. Модель от этого не меняется НИКАК, кроме того же самого случая, когда Вы зачем-то решите хранить в модели "подсвечиваем АК-47 как более скорострельный чем текущее помповое", как будто эта подсветка хоть как-то влияет на игру. А ведь у другой Вью, позвольте, этого нет? Что же, мы храним в Модели какие-то данные СПЕЦИАЛЬНО ради одного фриковью? А может это вью само позаботится о своих фриках?
Как параметр для определения частоты автоматической стрельбы, при зажатой клавише, когда второй и последующие события "выстрел" происходят не от нажатия юзером клавиши, а пока он не отпустит нажатую клавишу. Ну, отлично. Посылаем события "выстрел" с нужной частотой. Модель их получает и проверяет кого убили. И меняет кол-во патронов. А время то между выстрелами ей зачем считать и сообщать об этом Вью??? Что это за данные такие? Событие "выстрел" это команда от юзера. Это никак не результат размышлений Модели.
И даже количество патронов в обойме это - логика, относящаяся к под-модели оружия.Во-первых, это все-таки данные (но я рад, что Вы прониклись содружеством данных и логики). Во-вторых, кол-во патронов это единственные данные, которые я во всех своих сообщениях помещал в Модель, так что не знаю, кого Вы тут оспариваете))).
Перенос и просчёт этих параметров в виде - слишком уж грубое нарушение концепций MVC Не всё то данные, что может быть измеряно. Есть миллиарды данных, абсолютно ненужных игре (логике). У каждого объекта есть полсотни свойств, никак не влияющих ни на какие действия и вычисления. Не надо Модели хранить все это барахло и дергаться при каждом изменении чего-то, интересного ТОЛЬКО ТОМУ, кто изменился.
Меня только задело, что вы не сильно придерживаетесь концепций MVC (как мне показалось)Я не придерживаюсь концепций MVP, в которой модель это неподвижный ящик с ячейками, хранящий все подряд и открытый настежь, вью — такая же неподвижная картинка, каждый кадр берущая слепок с модели, в которой хранятся все данные О ВЬЮ, а контроллер содержит весь гений РНР-программиста, при каждом движении юзера (или даже при каждом кадре?) дергающий модель за все сиськи, чтобы вытащить из нее данные, обработать их и запихать в нее обратно через сотни геттеров и сеттеров. На фоне этого даже одно из базовых положений MVC "модель извещает [вью] о своем изменении" выглядит какой-то бессмысленной шуткой — зачем, если именно контроллер все посчитал и вот он, держит все эти изменения в руке? Зачем лишние связи? Ведь Вью могла бы не знать о Модели вообще ничего, общаясь только с контроллером, который итак уже имеет доступ ко всем данным Модели (а заодно и сотни "своих" переменных для временного хранения копий этих данных для рассчета)? Откуда же взялись эти события апдейта модели? Да просто классический (тонкий) контроллер НЕ ИМЕЕТ доступа к данным модели, потому и передать их вью — не может. Это логика MVC. В MVP я не вижу никакой логики, только подстраивание под технические особенности веб-программирования: отношения БазаДанных - СерверныйСкрипт - БраузерКлиента, которые невозможно трансформировать в MVC технически — все это в разных местах и на разных языках. MVP это попытка насколько возможно натянуть концепции MVC на эту ситуацию. А РНР-шники сегодня, наверное, составляют бОльшую часть всех программистов планеты?)) и дружно верят, что это "правильный MVC", даже не задумываясь, что сделать все как-то по-другому в их ситуации просто невозможно. Это не концептуальное, это технически неизбежное деление. И даже в нем, как ни верти, а у всех свистелок и перделок их собственная "логика" находится во вью, в виде какого-нибудь джаваскрипта. Никому не приходит в голову создавать и отслеживать на сервере и хранить в базе данных каждую падающую снежинку на новогодней странице.
elder_Nosferatu
01.10.2013, 05:16
Такой маленький дробовичек, а сколько текста из-за него! Наверное удачный пример подобрал для холивара ;)
@Wolsh
Сейчас объясню зачем данные о дробовике пихать в логику. Напомню с чего все началось:
Вот Вам ситуация: непрерывная стрельба.
В начале этого тысячелетия я подсел на вторую Диаблу, но, так как своего компа не было, мне приходилось бегать в игровой клуб. После дительного времени игры (я уже бодро шагал по второму акту) клубный админ пригрозил удалить мои сейвы и оторвать мне правую руку. Пичиной было сумасшедшее закликивание мышки, которое мешало окружающим и портило сам девайс. А я хоть огрызался и обиделся по началу, но в последствии все же был благодарен этому челу. Оказалось, что нажатие кнопки на враге не производит удар, а берет врага в фокус (под прицел) и удары будут наноситься автоматически до тех пор, пока я не отпущу кнопку. Для моего уставшего указательного пальца это было просто райское наслаждение!
Так вот, если таким макаром реализовать стрельбу, тогда игрок нажмет кнопку один раз и будет ожыдать, что стрельба не будет прекращаться до тех пор, пока он эту кнопку не отпустит или пока не закончились патроны. И выброс отстреляной гильзы/подача следующего патрона и перезарядка магазина - тоже части однокнопочного действия "СТРЕЛЬБА". По этому для логики процесса будут важны и скорострельность и количество патронов в магазине и их количество в кармане, а может и еще какие нибудь данные...
А в остальном Вы заставили меня задуматься... Да и не меня одного, я уверен!
Благодарю за умственную пищу. Буду размышлять.
А это я о чем?Как параметр для определения частоты автоматической стрельбы, при зажатой клавише, когда второй и последующие события "выстрел" происходят не от нажатия юзером клавиши, а пока он не отпустит нажатую клавишу. Ну, отлично. Посылаем события "выстрел" с нужной частотой. Модель их получает и проверяет кого убили. И меняет кол-во патронов. А время то между выстрелами ей зачем считать и сообщать об этом Вью??? Что это за данные такие? Событие "выстрел" это команда от юзера. Это никак не результат размышлений Модели.
Добавлено через 21 минуту
Еще раз, конспективно.
Вы считаете, что выстрел должна инициировать Модель, я — что Вью.
В Вашем случае необходимо пихать в Модель точное время анимации выстрела. То есть для такой Модели нужна СПЕЦИАЛЬНАЯ Вью, в которой анимация выстрела занимает точно такое время, которое установлено в Модели.
Теоретически, наверное можно научить вью растягивать и сжимать анимацию в соответствии с требуемым временем. Это Вы, конечно, не сочтете "логикой, которую пихают во вью". А логику "интерфейс сам решает, когда в нем произошло событие", Вы принять ну никак не можете?))) Удачи же.
alexcon314
01.10.2013, 11:11
Я как-то не совсем уловил суть дискуссии. Или таки речь идет об этом?
Нужно вынести стрельбу, в отдельную реализацию MVC.
ТС убедил всех, что стрельба - достаточно сложный процесс сам по себе с одной стороны (и это так, и речь может идти не только о стрельбе), с другой стороны, как справедливо заметили другие участники, он он не должен требовать каких-то сверх усилий по обслуживанию, не должен впиливаться в общую канву настолько, что потом не выпилишь). С третьей стороны )), хотелось бы все-таки как-то унифицировать его, подсовывя разные параметры в какую-то более менее общую реализацию.
Представляется такой алгоритм:
юзер взял оружие, создается MVC для стрельбы: модель заполняется данными о боезапасе и пр., вью отрисовыает собственно дробовик (или что там для стрельбы у нас?), ожидает "пли" от юзера, и готов отрисовать перезарядку, пламя и полет, котнтроллер их пасет и отсылает нужные для общей логики игры события в "главный MVC": боезапас уменьшился... пуля летит там-то... и т.п. Существует это все пока юзер не бросит дробовик и не возьмется, например, за ложку, чтобы пообедать. Прием пищи - тоже сложный процесс. Тогда вступает в действие "MVC приема пищи" и т.п.
Т.е. детализация процесса (стрельбы) выносится из общей логики в отдельны модуль, подпрограмму, если хотите. Тем самым, мы сможем предоставить кучу реализаций процесса (стрельбы) без изменений в мэйн-классах, у которых как бы и так забот своих есть. В то же время, мы имеем простор в плане самой реализации, MVC-же.
То же самое можно сказать и по всевозможным диалогам.
Алекс, тут проблема в том, что и при организации "дробовик это отдельное MVC дробовика" (что само собой правильно) вопрос синхронизации никуда не пропадает. Если, конечно, MVC дробовика это MVC.
Заявленная сложность в том, что на анимацию выстрела требуется время. Если выстрел инициируется из модели на основании ее данных о скорострельности оружия, то Вью придется рисовать четко под эту конкретную модель, либо проставить в Модели данные, взятые на основании анимации во Вью. Такой MVC попахивает не MVC, а вероятность рассинхронизации из-за фпс остается в деле. Ну, я попытался предложить MVC решение, заключающееся в том, что события интерфейса (выстрел) посылается интерфейсом (то есть Вью) — в соответствии с его собственным циклом анимации. Это же собственное событие Вью.
Однако тут есть неприятность, что числовые данные в модели о скорострельности, как харастериктика оружия для показа и сравнения, так и остаются зависимыми от анимации во Вью.
alexcon314
01.10.2013, 13:16
Ну, я попытался предложить MVC решение, заключающееся в том, что события интерфейса (выстрел) посылается интерфейсом (то есть Вью) — в соответствии с его собственным циклом анимации.
Я как бы за.
Я считаю, что отдельно стоящая Модель это спекулятивное понятие.
Модель для логики NodeLogic должна обновляться, анализироваться и отдаваться и всем этим занимается контроллер Модели. Такие же модели должны существовать на уровне сервисов и видов. Соответственно первые обновляют данные для логики и вида, а вторые для логики и сервиса.
Добавлено через 12 минут
Т.е. данные для логики обновляются по событиям вида или сервиса, ей передаются условно актуальные NodeView или NodeService в формате JSON || XML.Это кому как нравится.
Dukobpa3
03.10.2013, 20:06
Паттерн XML-MVC в действии.
Добавлено через 4 минуты
Касательно выстрела.
Задачу подобную решал но это не совсем выстрел был.
Это была клиент-серверная модель с логикой на сервере (в модели).
Математика сервера обновлялась раз в секунду. Вью(клиент) рисовалась как там ей удобно, со своим фпс.
И вот раз в секунду все значения вью(модели клиента) перезаписывались новыми значениями с сервера, т.е. просто периодическая синхронизация происходила.
А расчеты математики были сугубо на сервере с частичным дубляжом в клиенте с периодичностью в секунду. Думаю для выстрела этого было бы достаточно, если это не мультиплей шутер с большой толпой народу. Но даже и в таком случае схема рабочая, разве что "тики" в модели сделать чаще чем раз в секунду. А вью еще чаще.
т.е. получается мы и красоту видим, и математика не ломается, и вью ничего не решает.
Вью ничего не решает, но она может подействовать на логику и пройти дальше на сервер. Допустим, если у игрока попытки кончились логика может сразу выдать для своего вида событие GAME_OVER, но вот должна ли?
Игры все таки лучше делать как вебсервисы и логика должна меняться от серверных событий, а не по событиям лейаута. Хотя на первый взгляд кажется, что так проще :)
Akopalipsis
09.10.2013, 16:48
Начав читать небольшое описания шаблона MVC, я сразу понял что читать нужно всю книгу и о всех шаблонах. Прочитав и переписывая все примеры из книги ( переписывал для того, что сразу я не смогу запомнить и понять смысл всего, а наглядные примеры помогут восстановить в памяти книгу ) у меня появилось ещё больше вопросов... Но я задам только два, первый - почему все с радостью обьясняют о работе MVC, но не кто не говорил, что это не шаблон, а набор шаблонов?) Ведь говорить о MVC нельзя не зная другие шаблоны)
И второй - может знает кто нибудь, где можно посмотреть пример грамотного MVC? Сейчас я по другому смотрю на RL и мне кажется, что это именно то что и будет грамотным, но всё же очень хочется посмотреть, что такое много моделей и много контроллеров. Потому что в моей голове складывется картина, что главные фигуранты должны быть чем то абстрактным.
Dukobpa3
09.10.2013, 17:21
MVC - архитекрутный паттерн.
Он самодостаточен.
Но, что очевидно - когда вдаетесь в дискуссии об архитектуре , подразумевается что к этим самым дискуссиям уже готовы, т.е. определенный набор задач решать уже приходилось, и хоть сколько-нибудь знакомы с методами их решения.
Вот и получается - чтоб говорить об архитектуре - нухно хоть немного понимать другие паттерны.
И MVC - не исключение. Так что я могу подитожить что тут вопрос не в MVC, а в самой тематике беседы.
Примеры грамотного мвц есть в вики:) И пример грамотного мвц это три класса - контроллер-вью-модель, ты уже и сам такой же написал в другой теме. Но реальные задачи обычно состоят из пачек классов, и тут уже вопросы другого уровня.
Akopalipsis
09.10.2013, 17:34
и тут уже вопросы другого уровня.
Вот как раз я наверное и дошёл до этого уровня. Все мои вопросы с примером трёх классов были лишь для того, чтобы грамотно спросить об самой архитектуре. Но я не знал что спрашивать, так как не знал правильных терминов. Теперь я более менее осведомлён и хочется уже говорить о MVC в глобальных масштабах. Но я пока несколько дней уйду в повторное чтение и попробую сам что то сделать, чтобы было о чем говорит. Всё таким сложным кажется...
Akopalipsis - я вообще не понимаю, как можно перейти на MVC без начального понимания происходящего. По крайней мере, нужно сначала научится делать обычные приложения, не на MVC, совершенствуя себя, понимать, что такое фабрика ( вот уж она точно везде ) и т.п. Разобраться с событиями и их составляющими . И только когда есть определенный опыт в программировании вообще, переходит на MVC - сама природа позовет. По крайней мере у меня так было.
Akopalipsis
09.10.2013, 17:50
Akopalipsis - я вообще не понимаю
А я не могу понять, как создание чего то простого может приблизить к MVC? Зачем учится неправильно?
Dukobpa3
09.10.2013, 17:54
Дада, Инфокор вон постиг дзен:)
Зачем учится неправильно?
Не учиться не правильн, а просто учиться, хоть как-то. На реальных задачах. Академические знания без реального применения - как с гуся вода.
А вот когда попробовал сделать это - получилось некрасиво.
Попробовал сделать это - не получилось.
Попробовал сделать это, но интуиция подсказывает что можно ведь лучше.
Тогда уже и знания в помощь будут.
Akopalipsis
09.10.2013, 19:14
Вопрос именно технический - Синглтон, класс который создается единожды и всякий раз возвращает созданный ранее экземпляр. В примерах про него говорилось, как о наиболее частом в применении и про его применение говорили, что он подходит для ведения счёта игры и прочего. Но на форуме я не один раз читал, что его мало кто использует. И появляется вопрос - уделяют ли значение этому шаблону опытные разработчики, то есть Вы, или стоит забыть о нём и помнить, что для этих нужд есть модель ( сохранять значение в свойство ) ?
Не знаю как кто, я не использую синглтон вообще. В программировании много извращений на самом деле.
Вам как человеку работающему не в команде , достаточно просто познакомится с ним, - реализовывать не придется. А вот в команде - может и потребоваться, все зависит от проекта. Что такое синглтон? Объект, который не может иметь более 1го экземпляра. Что такого может случится срочного в жизни, чтобы такое понадобилось ой как сильно? Верно - ничего. Забудьте
Dukobpa3
09.10.2013, 19:18
Лучше уж у тебя вся система будет из синглтоном, чем ты наколбасишь уникальных идентичных инстансов и запутаешься в них.
У меня сейчас собственно так и есть.
Корневые Модели все синглтоны.
Корневые Контроллеры все синглтоны.
Корневые Вью все синглтоны.
Корневые - имеется в виду точки входа в контроллеры модели и вью. Но внутри каждой большой модели может быть множество мелких, в которых уже в зависимости от задачи.
Но вцелом за несколько лет архитектура контроллера и модели устаканилась, так что модели как близнецы и контроллеры тоже. А вот вьюхи уже могут быть очень разнообразны.
Нечто похожее на пур-мвц + роботлегс. Но фреймворк сам писал.
Dukobpa3 - это все песни извращений , как я уже сказал. Разницу корневой модели синглтоном или нет - никакой. Почему? Да потому, что ты разработал это и знаешь - что 1 только инстанс у модели, а не 500 шутк. Да и вообще, как можно запутаться в видах моделях и контролах? Да один корневой список справа в FD и так все решает, нет конечно я не говорю про 1000.000 классов для какой нибудь масштабной игры, там уже подход другой, а для средней руки приложения в 20-50 классов , например того же казино, что я делал - никаких синглтонов не надо
Dukobpa3
09.10.2013, 19:25
В синглтоне и статике абсолютно ничего плохого нету.
А бонусов предостаточно. Во всяком случае синглтоном ты непоправимого добра своему проекту не нанесешь(ну конечно если не будешь его дергать отовсюду, а придерживаться какой-то идеалогии).
Если начнется разгильдяйство на тему: "ну а че, синглтон же, хоть и модель, но во вьюхе могу его получить, так почему бы из вью его не поменять" - то я тебе вообще ничего гарантировать не могу ;). А если то что это синглтон просто даст тебе более удобный доступ оттуда ОТКУДА ЕГО НАДО ПОЛУЧИТЬ, а не откуда попало. То это просто сэкономит время.
Вот верный разговор СТАТИК и СИНГЛТОН . Почему второе, а не просто облегченное первое а ? Я же говорю извращения надо прекращать. Раз уж пошла пьянка о прост(а)оте - то обычный статик самое понятное и простое и экономит время. Не знаю, мое мнение неизменно - статики используются для Utils и только. Для каких то быстрых вычислеений, преобразований, трейсингов и т.п. - но никак не для архитектурного решения.
Dukobpa3
09.10.2013, 19:41
С удовольствием посмотрю на умл-диаграмму твоего хоть сколь-нибудь сложного приложения.
А потом продолжим.
Увлечение синглтонами пошло от подхода один класс - один функционал. Т.е. подразумевается классовая специализация. Мне лично такой подход не близок тоже.
Dukobpa3
09.10.2013, 19:48
На вашу архитектуру я бы тоже взглянул.
Но, помнится, я уже в очереди.
Мне близок, подход который используется в VBA for MS Office или Visual Lisp в Автокаде. Есть ядро и есть API для него. Принимаешь такое API - хорошо. Нет - ищи другой фреймворк.
Добавлено через 9 минут
На вашу архитектуру я бы тоже взглянул.
Но, помнится, я уже в очереди.
Она перманентно в сборно-разборном состоянии. Но основа та жа самая - Ядро, Коммандер(Контроллер) Модели для Сервиса, Вида и Логики. Модели представлены в виде XML нод, что позволяет не плодить кучу геттеров и сеттеров, а обращаться к нужным сущностям (сервисам, дисплеям, данным), через xpath запросы.
Вид общается с Сервисом, Сервис с Логикой, Логика с Видом.
Dukobpa3
09.10.2013, 20:03
Я пожалуй или еще в очереди постою, или всё-таки посмотрю на реализацию наконец-то. Или uml, в крайнем случае. А про "ядро xml-mvc" я уже наслышан.
Dukobpa3 - благословен будешь
Благославлен на стояние в очереди.
carrotoff
10.10.2013, 10:53
достаточно просто познакомится с ним, - реализовывать не придется
Что такого может случится срочного в жизни, чтобы такое понадобилось ой как сильно? Верно - ничего. Забудьте
Это все похоже на слова дилетанта. К ним не стоит прислушиваться.
ей передаются условно актуальные NodeView или NodeService в формате JSON || XML.Это кому как нравится.
Модели представлены в виде XML нод
Babylon, у вас явная передозировка слова XML в ваших сообщениях. С вашего позволения, я тоже встану в очередь за Александром.
Psycho Tiger
10.10.2013, 14:57
in4core, я, конечно, не хочу тебя расстраивать, но:
1) синглтон и статик связаны примерно как гранённый стакан и 3 закон ньютона
2) синглтон не обязан быть доступен глобально. Предпосылки сделать его глобальным ничем не отличаются от предпосылок дать не-синглтону глобальный доступ.
3) stage – тоже синглтон. root – мультитон. Другими словами, считая нормальным давать синглтону глобальный доступ ты поощряешь запись (ну раз синглтон то че бы нет) Main.stage = stage
4) сингл/мультитоны отлично показывают себя в ленивой инициализации.
5) мультитон не позволит создать объекты, если их стоит взять из пула.
6) в каком-то приложении таблицы-футбола, которое ты гордо демонстрировал до своего первого бана в какой-то момент полетели ошибки по обращению к null'у. Подробностей я не помню, но я подметил что ты забыл скомпилировать флешку в релизном режиме и из стэктрейса было понятно, что кто-то старый обратился к новому экземпляру объекта и не нашел у него то что искал. Если бы ты осознал, что объекты можно не пересоздавать и связал бы себе руки синглтоном – я бы злорадствовал над другой найденной ошибкой.
Я тебя тоже расстрою. Я вкурсе, что такое синглтон, и что глобальным ему быть совершенно не обязательно. Про футбол - хз, исходники переданы 2 года назад, его может кто еще пилит щас или еще чего. А с нулем, да, чтож поделать, раз сервер не доделан как положено, ты ожидаешь например 0.5 а тебе присылают DTT-текст какой нибудь, который в протаколе не заявлен - а по скольку от коэффициента, например, может , что то строится, а из за текстовой строки, не преобразуемой, мы сразу увидим ошибку - то практика себя оправдывала, и наверное более 2х месяцев, мы только с сервером разбирались, почему он косячет, так кстати помоему до конца и не разобрались - null стало приоритетной фичей)
Psycho Tiger
10.10.2013, 18:06
Увлечение синглтонами пошло от подхода один класс - один функционал. Т.е. подразумевается классовая специализация. Мне лично такой подход не близок тоже.
Кстати, вот здесь не уловил. Вы против SRP (http://en.wikipedia.org/wiki/Single_responsibility_principle)?
Я не вижу большого смысла в SPR при использовании ядра, но для плагинов сойдет.
Dukobpa3
10.10.2013, 18:25
Такие уж нынче времена.
Ядро - всему ядро!!
Я использую, тот или иной подход в зависимости от моей субъективной целесообразности .
Akopalipsis
10.10.2013, 22:16
Ещё один актуальный вопрос - как Вы событиями между триадой обмениваетесь, как в повседневной жизни - послал\принял или стеки делаете?
Dukobpa3
10.10.2013, 22:18
Ивенты и ивенты себе. Без бубна.
Akopalipsis
10.10.2013, 22:24
А то у меня вот какая проблема - делая минимальный пример без отдельных инстенсов и апдейтов.
При запуске конструктора я в цикле вызываю пять раз метод который набивает двухмерный массив цветом.
И очень удобно иметь этот метод, так как в дальнейшем при его вызове, будет добавляться ещё вложенный массив и диспатчить вью о его добавлении. Но при первом запуске вью ещё не готова принимать события. И единственное что приходит в голову, это во всех моделях сделать метод update и вызывать его после того как будет готовы все вью. Это будет хорошо или есть какое то другое обыденное решение?
for (var i:int = 0; i < 5; i++)
{
this.createGraf();
}
private function createGraf():void
{
var column:Vector.<uint> = new Vector.<uint>();
var length:int = _color.length - 1;
var color:uint;
for (var i:int = 0; i < COLUMN; i++)
{
color = Math.round(Math.random() * length);
column.push(color);
}
_grafModel.push(column);
dispatchEvent(new Event(GameEvent.MODEL_CREATE_COLUMN));
}
Dukobpa3
10.10.2013, 22:28
другое обыденное решение - когда к готовой вью прикрутили модель она первым делом сразу же смотрит что там есть в модели, без событий.
А потом уже события дают вьюхе команду обновиться с того состояния которое біло до нового.
Akopalipsis
10.10.2013, 22:28
И в целом, ведь считается плохо в конструкторе что то запускать, только инициализировать?
когда к готовой вью прикрутили модель она первым делом сразу же смотрит что там есть в модели, без событий.
я тоже сначала так подумал, но сразу увидел недостаток и пришёл сюда спросить. Недостаток вот в чем - когда я вызываю метод рисования кубов, вью лезет за двухмерным массивом графов. В этом методе она проверяет кол-во вложенных массивов и длину каждого вложенного.
Так как вью добавляет только что созданный массив в двухмерный массив созданный на уровне класса, то приходится делать два цикла, один вложенный в другой. И все хорошо, но в следующий раз, когда модель пошлёт событие, то нужно создать всего один массив, а в методе уже находятся два вложенных цикла, которые добавят много лишнего... Буду ещё думать....
Dukobpa3
10.10.2013, 22:29
Зависит от ситуации. Ничего дурного в этом нет.
Добавлено через 1 минуту
Другое дело что тяжелый конструктор может притормозить всю систему (один - нет, но если вы часто используете много кода в конструкторах, это не ок).
Akopalipsis, перед тем как кодить, а тем более задавать вопросы по теме известной только Вам неплохо бы рассказать о своих планах.
Добавлено через 2 минуты
Как правило вью ждет данные от модели или от сервиса. Если данные готовы чтобы их отрендерить во вью действуйте.
Akopalipsis
10.10.2013, 22:43
Akopalipsis, перед тем как кодить, а тем более задавать вопросы по теме известной только Вам неплохо бы рассказать о своих планах.
Наверняка Вы видели недавнею тему с игрой линии. Вот я её пытаюсь сделать.
Добавлено через 10 минут
Немного поспешил, есть решение без чего то лишнего..
вью никуда не лезет и не проверяет. Сколько можно повторять одно и тоже. Учите матчасть. Т.е. MVC
Dukobpa3
10.10.2013, 23:02
Повторяли бы адекват, был бы другой разговор.
Вью имеет ссылку на модель на чтение. Чем она и занимается. Читает.
Akopalipsis
10.10.2013, 23:17
Babylon в книге для as3 написано, что вью имеет ссылку на модель.
Она в неё лазиет и её слушает. Так же вью и на контроллер ссылку имеет. Контроллер на модель.
И так же стоит заметить, что контроллер не создает вью и модель.
Dukobpa3, читать вью может. Зачем ей куда то лезть и что-то проверять при этом?
Добавлено через 1 минуту
по совершению события срабатывает хэндлер откуда вью и берет данные.
Что за событие? // Модель создается раньше чем Вью
Где этот хэндлер?
Вью берет данные из хэндлера? // Из хэндлера? О_о
Akopalipsis
10.10.2013, 23:55
Вот модель графов
package game_lines.model_package
{
import flash.events.Event;
import game_lines.event_package.GameEvent;
public class GrafModel extends GameModel implements IModel
{
private var _grafModel:Vector.<Vector.<uint>>;
private const COLUMN:int = 10;
private var _color:Vector.<uint>;
public function GrafModel()
{
_grafModel = new Vector.<Vector.<uint>>();
_color = new Vector.<uint>();
_color.push(0x5259E4, 0xA9E254, 0xE35E53, 0xDEE155);
for (var i:int = 0; i < 5; i++)
{
this.createGraf();
}
}
private function createGraf():void
{
var column:Vector.<uint> = new Vector.<uint>();
var length:int = _color.length - 1;
var color:uint;
for (var i:int = 0; i < COLUMN; i++)
{
color = Math.round(Math.random() * length);
column.push(color);
}
_grafModel.push(column);
dispatchEvent(new Event(GameEvent.MODEL_CREATE_COLUMN));
}
/* INTERFACE game_lines.model_package.IModel */
public function get grafModel():Vector.<Vector.<uint>>
{
return _grafModel;
}
}
}
package game_lines.view_package.game_area
{
import flash.display.Sprite;
import flash.events.Event;
import game_lines.event_package.GameEvent;
import game_lines.view_package.GameView;
public class GameArea extends GameView
{
private var _model:Object;
private var _cubeStorage:Vector.<Vector.<ICube>>;
public function GameArea($model:Object=null, $controller:Object=null)
{
super($model, $controller);
_cubeStorage = new Vector.<Vector.<ICube>>();
_model = $model;
_model.addEventListener(GameEvent.MODEL_CREATE_COLUMN, model_modelCreateColumnHandler);
this.model_modelCreateColumnHandler();
}
private function model_modelCreateColumnHandler(event:Event=null):void
{
var cube:Cube = new Cube(30, 30, 0xDEE155);
super.addChild(cube);//вот сдесь по событию в модели вью лезет в неё и берет значения через геттер
}
}
}
Единственное что мне не нравится, что модель пошлёт пять первых диспатчей в никуда.
Никто никого "в никуда" не посылает. Что за мистика на ровном месте? Диспатч это вызов коллбека. Нет коллбека — нет диспатча.
хэндлеры у нас в классах контроллеров.
public function onNodeLogicChange($e:NodeLogicEvent) :void
{
Engine.commands.refreshView($e.logic.INode);
}
Как то так...
Akopalipsis
11.10.2013, 00:19
Нет коллбека — нет диспатча.
Честно сказать я с ними всего раз сталкивался, мне показали и сказали, что вроде лучше чем события.
Сам принцип их я понимаю, но не знал что события это как раз они. Сам я их в чистом виде не использую почему то.
Добавлено через 1 минуту
хэндлеры у нас в классах контроллеров.
Но тогда это будет "жирный контроллер" ?
Если же пугает создание "лишнего" экземпляра события, проверьте наличие зарегистрированных слушателей с помощью hasEventListener().
И Вы таки настаиваете на создании кастомного класса события GameEvent? Класса, который должен быть известен И модели, И вью? Мы ведь как то обсуждали эту тему.
Dukobpa3
11.10.2013, 00:29
Так же вью и на контроллер ссылку имеет.
Вью не имеет ссылки на контроллер.
Akopalipsis
11.10.2013, 00:30
И Вы таки настаиваете на создании кастомного класса события GameEvent?
Так вроде решили, что нужно слать нативные события, а красивое имя за счет класса с константами?
dispatchEvent(new Event(GameEvent.MODEL_CREATE_COLUMN));
private function model_modelCreateColumnHandler(event:Event=null):void
Добавлено через 13 минут
Вью не имеет ссылки на контроллер.
Код из книги -
var model:IModel = new Model( );
var controller:IKeyboardInputHandler = new Controller(model);
var view:View = new View(model, controller, this.stage);
А ещё там есть -
Model
Needs to have a reference to views
View
Needs references to both the model and controller
Controller
Needs a reference to the model
Akopalipsis
11.10.2013, 00:45
Вот как жить с MVC, когда думаешь что книга то только на пользу)))
что за книга?
ActionScript 3.0 Design Patterns
Книга просто безумно интересная! Жалко только что она, как я понимаю, конец в дискуссии не поставит.
Wolsh, я как самый дотошный, нашёл старую тему и проверил, у меня сделано так, как Вы и учили!)
Про ссылку на контроллер это нормально, это один из вариантов реализации, когда Вью не посылает события контроллеру, а вызывает его методы напрямую. Для толстых контроллеров это недопустимо, но тонкие пишутся специально для конкретных Вью, и такой способ возможен.
Akopalipsis, извиняюсь, я думал GameEvent это класс события, а не просто список констант. Почему? Потому что не "GameEvents" )))
Akopalipsis
11.10.2013, 01:29
Потому что не "GameEvents" )))
я когда думал как назвать, то вспомнил, что во всех примерах которые я видел писали events, так принято?
Книга просто безумно интересная!Почитайте классический труд (http://www.books.ru/books/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-2920644/?show=1) "Банды четырех" (GoF). Множественное просветление гарантируется. Правда, развернутого описания MVC в ней нет (так как это не паттерн), только краткое, где-то во введении.
так принято?Список подразумевает множество. Event это Событие. Events это множество, то есть либо хранилище объектов, либо список. Еще лучше EventTypes, я думаю))
Почитайте классический труд (http://www.books.ru/books/priemy-obektno-orientirovannogo-proektirovaniya-patterny-proektirovaniya-2920644/?show=1) "Банды четырех" (GoF). Множественное просветление гарантируется. Правда, развернутого описания MVC в ней нет (так как это не паттерн), только краткое, где-то во введении.
Введение. В нем много проясняется. Можно даже не смотреть на описанные там паттерны, да кого они интересуют вообще! У нас тут, в основном, синглетоны в ходу. Так и живем.
Я использую, тот или иной подход в зависимости от моей субъективной целесообразности .
Тоже бы взглянул на легендарную связку ЧЬД-ЬМС.
Dukobpa3
11.10.2013, 01:42
Выкинь книгу.
У контроллера ссылки и на модель и на вью.
У модели ссылок ни на что нету.
У вью ссылка только на модель.
Но если книга по какому-то яваскрипту например то "модель имеет ссылку на вью" может означать то что модель регистрирует в себе коллбеки от вью.
Но все-равно как-то уныленько это выглядит.
Добавлено через 2 минуты
Да что ж тут такая активность, пока ответил уже еще одну страницу накатали.
Akopalipsis
11.10.2013, 01:50
Почитайте классический труд "Банды четырех" (GoF).
Обязательно!! Спасибо.
У вью ссылка только на модель.
Ну на самом деле, если быть честными - то ссылка есть. В виде хэндлера в классе контроллера.
Контроллер же слушает события вьюшки.
Вообще предлагаю ещё почитать на тему:
http://www.flasher.ru/forum/blog.php?b=554
там я ссылок покушать принёс.
Dukobpa3
11.10.2013, 14:16
В виде хэндлера в классе контроллера.
Ну все-равно не совсем же.
Даже если коллбеками или сингналами связывать то там будет делегат, но не ссылка на екземпляр, хотя зависит от реализации обсервера событий.
Мы тут немного о другом, а это всё уже высокая материя, которая запутывает неокрепшие умы.
Akopalipsis
11.10.2013, 21:25
Котяра Спасибо! Вторая ссылка мне понравилась, есть от чего оттолкнуться или даже можно сказать, что она немного укрепила полученную раннее информацию.
А вот по поводу книги "Банды четырех" (GoF) я немнго расстроился, она не для as3 и мне немного трудно её понимать.
Многие паттерны гофа не нужны в ас3, т.к. в ас3 нет ограничений, которые есть в java.
На мой вкус нужно понять следующее:
обёртка-делегат-бридж, стратегия, фабрика, понимание сущности обсервера и модели событий конкретного языка.
Многие паттерны гофа не нужны в ас3
Какие именно?
Ещё моих любимых ссылок покушать вот вам:
http://habrahabr.ru/post/113128/
http://habrahabr.ru/post/88443/
Dukobpa3
12.10.2013, 03:14
модели событий конкретного языка
Вот это ты уже загнал.
Далеко не все языки на ивентах построены. "Кошерные" платформы зачастую такой радости не имеют, максимум сигналы и коллбеки.
Само понятие асинхронных событий необходимо реализовывать только при наличии виртуальной машины и однопоточного приложения. Ибо многопоточность выносится в виртуальную машину, и чтоб дать возможность хоть как-то рулить приложением приходится крутить асинк ивенты.
Если абстрагироваться от ВМ - получаем многопоточность и пуши в коллбеки между потоками.
Akopalipsis
13.10.2013, 14:50
Котяра по второй ссылке меня нет, это точно, а вот вторая - да...
Этим я просто весь заражён, хоть со временем сам замечаю, что отхожу от этого.
И я специально усложняю все не для того, чтобы в будущем использовать ( я не раз себя ловил, что даже двух недельный код не понимаю ), а с мыслью - чтобы потом легче было.
Добавлено через 24 часа 18 минут
Добавлено -
Когда я читал форум, то у меня сложилось впечатление ( которое сейчас мне кажется некорректным )
что верховный фигурант триады создает подклассы. То есть я трактовал это вот как -
package
{
public class BaseView
{
public function BaseView(model:Object)
{
//это главная вью ( абстрактный класс )
}
}
}
package
{
public class View extends BaseView
{
private var _model:IModel;
public function View(model:Object)
{
_model = model as IModel;
super(_model);
//это главная вью приложения
var subView:BaseView = new BaseView();
}
}
}
package
{
public class SubView extends View
{
private var _model:ISubModel;
public function SubView(model:Object)
{
_model = model as ISubModel;
super(_model);
//это субвью
}
}
}
Но как показывает практика, это не правильно, так как модели у все разные и передовая субмодель в супер класс вызывает ошибку. А делать надо наверное -
package
{
public class BaseView
{
public function BaseView(model:Object)
{
//это главная вью ( абстрактный класс )
}
}
}
package
{
public class View extends BaseView
{
private var _model:IModel;
public function View(model:Object)
{
_model = model as IModel;
super(_model);
//это главная вью приложения
var subView:BaseView = new BaseView();
}
}
}
package
{
public class SubView extends BaseView
{
private var _model:ISubModel;
public function BaseView(model:Object)
{
_model = model as ISubModel;
super(_model);
//это субвью
}
}
}
То есть наследовать все классы от BaseView...?
Dukobpa3
13.10.2013, 14:57
Конечно.
Мне кажется ты не совсем понимаешь суть наследования.
Они могут вообще друг друга не наследовать и никакими родственными связыми не связываться.
Главное чтоб суть сохранялась - контроллер слушает вью и рулит моделью, модель меняет данные и кричит об изменениях, вью слушает модель и меняется согласно того что в модели поменялось плюс умеет кричать о действиях пользовавтеля.
А наследование друг друга подряд как в первом варианте для это ситуации вообще ошибка, а для остальных - крайне редко нужно.
(наследование больше двух-трех уровней чаще всего неоправдано, обычно достаточно одного базового класса от которого наследуются все однотипные, это не закон и не правило, но если в цепочке наследования штук пять классов - я уже задумаюсь о том, что архитектура, скорее всего кривая)
Добавлено через 6 минут
И мне кажется тут каша с понятием главной вью.
Ты перепутал родителя в цепочке наследования с родителем на уровне приложения.
Часто и там и там говорят "родитель", но если наследование - то родитель - это суперкласс, от которого мы наследовались(этот вариант не совсем корректен, так как это не родитель, а суперкласс).
А во втором случае - родитель - класс который создает екземпляр текущего класса. Этот вариант правильный. В таком случае кто-то будет главным, и будет создавать своих детей.
И главная вью во всех этих разговорах - подразумевалось что это вью, у которой есть внутри нее еще какие-то вью. Получается некое дерево вьюх, которое всё создается одной главной вью. И вот эту главную вью создает, например главный контроллер. Т.е. для главной вью родителем будет главный контроллер.
Akopalipsis
13.10.2013, 15:06
Dukobpa3 так как я сами понимаете глупый, то мне сложно продолжать не получив подтверждение.
Пошёл потихоньку продвигаться дальше. Спасибо!
в суперкласс мы сносим общий код, а то, что хотим изменить оверрайдим в наследниках и эти наследники могут быть частью mvc
Я начинаю проектирование приложения с построения структуры данных, а не с классов.
Akopalipsis
13.10.2013, 17:16
Я начинаю проектирование приложения с построения структуры данных, а не с классов.
Этим я который день и занимаюсь. По первому разу сложно всё, то о чём я много говорил, в деле, как я предполагал, оказалось иначе. Как мне кажется сейчас, процентов девяносто лёгкости работы MVC зависит от построения базовых классов, которые будут применяться всегда, в любом проекте.
MVC можно строить и без них. У вас пока ничего нет, а вы уже обобщаете. Глупо!
Добавлено через 1 минуту
я вам приводил пример с видеоуроками. вы его проигнорировали похоже.
http://habrahabr.ru/post/141477/
Akopalipsis
13.10.2013, 17:37
я вам приводил пример с видеоуроками. вы его проигнорировали похоже.
Как это я его проигнорировал, если я даже Вам отдельное спасибо за него говорил.
Тогда я искренне не понимаю происхождение ваших вопросов и тот код который вы тут показываете.
Вы повторили уроки за Артемом? Если нет, то я не могу сказать что вы разобрались.
Akopalipsis
13.10.2013, 18:11
Вы повторили уроки за Артемом?
Да, у него есть базовый класс, от которого он наследует все классы триады.
Но это немного наверное неправильно? Ведь тогда будет установлена жесткая связь всего приложения.
Возможно те книги которые я читал устарели и все слова о имплементациях и связях в них уже не актуальны.
Ну или я, как любой начинающей, хочу сделать - как можно правильней)
Добавлено через 13 минут
Wolsh статья более чем актуальна и я не один раз думал над схожим смыслом.
Когда я услышал о RL2 то сразу же начал вникать в него. Мне было очень сложно и я его немножечко от него отстранился. Прочитав книгу паттернов я сразу вспомнил о RL2 и его запутанность стала мне немного понятней. Тогда я ещё думал - как говорят, что RL2 лучший из имеющегося и какую бы архитектуру я не выбирал, она все равно будет не лучше предложенного в фраймворке. И тогда я решил, что как только сам что то сделаю, то вернусь к нему и уже с умным взглядом оценю его.
Но так же есть одно НО, когда я просматривал офффорум, то наткнулся на вопрос о низкой производительности в игре и ответ на него был - мы не рекомендуем RL2 для создания игр.
Но в общем плане, я не куда не тороплюсь и просто пока учусь, а там уже будет видно.
вы сделаете хотя бы тупо скопировав чужой подход. Пусть он для вас станет идеальным. Вы все равно пока не видите разницы между правильным и как можно правильным
elder_Nosferatu
15.10.2013, 21:07
Да-а-а-а! Много вы тут без меня наворотили.
Извиняюсь за отсутствие - пережил переезд, об интернете даже и думать не приходилось...
Хоть беседа уже начала жыть своей жизней, а меня все забыли, но вот он я и у меня есть вопрос или скорее обращение к тов. Wolsh`у:
После длительного отсутствия пришлось перечитать топик, чтобы все вспомнить. Я, со свежей головой, посмотрел на Ваши высказывания, особенно #33 (http://www.flasher.ru/forum/showpost.php?p=1147396&postcount=33) и #35 (http://www.flasher.ru/forum/showpost.php?p=1147404&postcount=35). На чем держится Ваша голова? Если бы я сам пришел к таким выводам, то никакой супер-скотч не помог бы мне сохранить свою голову на плечах... Пришлось в корне пересмотреть свои взгляды на вид и на МыВыЦы в целом. Огромное спасибо за умственную пищу, ибо подумать будет над чем! Правда все это рушит мои ожидания на счет MVC. Я надеялся достигнуть архитектуры, независимой от выда. Но, наверное, для флеша это не вариант. На много эффективнее будет делать по вашему, ато действительно прийдется каждый кадр ваять свежый слепок вида из модели, что превратит даже слабенькую игру в action-slideshow.
Akopalipsis
15.10.2013, 21:21
elder_Nosferatu надеюсь, что отсутствие интернета не повлекли за собой отказ от чтения и Вы книгу всё же почитали. И тогда у меня к Вам вопрос как к опытному программисту, который может различить грамотную архитектуру от бреда - как кол-во патрон может повлиять на работу модели? Зачем записывать в модель каждый выстрел кол-во патрон?
Добавлено через 23 минуты
Пример из жизни - из - за жажды знаний решил проверить ютуб на наличие уроков mvc. Все уроки по фраймворкам и только один раздел вызывал надежду. Ткнув на первое видео я обнаружил именно то что и хотел, базовые классы от которых наследуются, но как оказалось посмотреть их нельзя, потому что автор закрыл свой первый урок и тем самым оставил меня с тем же вопросом. И я начал смотреть что есть. Так вот там автор на примере создания игры пинпонг цвет шарика в модель поместил. И я сразу выключил.
Зачем цвет шарика в модели... Так же мне кажется там и нечего делать информации о кол-ве патрон.
Потому что это настоящие игровые данные, такие же как здоровье, мана и стамина.
Они сохраняются в сейве. Они отображаются разными вью — и HUDом во время боя, чтобы игрок видел сколько у него патронов в обойме, и окнами торговли, инвентаря или крафтинга. может быть даже влияют на вес или еще какой-нибудь параметр вроде "готовность к миссии", или участвуют в квесте "принеси мне сто патронов". Это данные.
Кроме того, окончание патронов в обойме это событие, требующее сменить обойму / рожок автомата. И это не юзерское событие, как нажатие курка. Это изменение состояния оружия, переход в состояние ожидания смены обоймы, которую юзер должен инициировать, нажав соответствующую клавишу (обычно R))). Хотя, технически этот момент не важен — патроны кончились и автомат просто не реагирует на нажатия "курка", юзер должен сообразить что нужна смена обоймы. Да, пожалуй Модели нет до этого дела. Но количество патронов это мастхав.
Dukobpa3
15.10.2013, 21:47
Если от цвета шарика завист его поведение - его место в модели.
от кол-ва патронов завист кол-во убитых врагов - так что кол-во патронов нужно хранить в модели.
Добавлено через 57 секунд
ну и то что волш ответил... банально при перезапуске игры играть разными шарами не ок. Я хочу играть зеленым - буду играть зеленым.
elder_Nosferatu
15.10.2013, 22:31
@Akopalipsis
Жаль нет нужног смайлика, попробую описать словами:
[Стою возле Wolsh`а иподдакиваю]
Akopalipsis
15.10.2013, 22:41
elder_Nosferatu если бы эти посты написал кто то другой Вы бы все равно эти слова сказали?
Тогда идите в соседнею тему и напишите, что я Вам поддакиваю! А то я там сказал, что Вы хороший вариант предложили, который я опробовал.
elder_Nosferatu
16.10.2013, 00:03
Да Wolsh`а я уважаю, особенно за его терпение к непонимающим (истинный педагог). Но не его авторитет меня вдохновил, а мысли, которые он выдал! И я не сразу проникся его словами. По началу я даже пытался вести с ним спор, который прекратили мои оффлайновые дела. Но сегодня внимательно перечитывая эту тему я прозрел.
Когда я только открывал эту ветку я этому подходу не радовался, потому что неправильно его использовал. У меня модели были слишком умными и пытались быть в курсе всех мелочей. По этому виды постоянно рапортовали о своих действиях. Wolsh же показал мне что модели нужно абстрагироваться от мирской суеты. А виды должны максимально обрабатывать свои личные данные и рапортовать только о результате.
Например мой переезд: Вызвали мы грузовик и начали бегать с вещами с 5-го этажа на первый. Тот еще ВИД был! Пакеты с одеждой, коробки с книгами и посудой, два компа и торчащие провода, мебель в конце концов. А шоферу грузовика плевать. Он ни разу не спросил, долго ли еще, помочь ли нам - он просто стоял в сторонке, покуивал сигаретку и ждал команды "Все, поехали!". Та же ситуация повторилась и во время разгрузки.
А был еще мой приятель, которого я взял себе в подмогу. Он постоянно меня спрашивал "что теперь нести?", "а на какой этаж потом выносить?", "где можно руки помыть?" и т.д. В конце концов и водила и кореш справились с поставленой задачей, но с первым я почти не разговаривал, а второму постоянно приходилось отвечать (даже тогда, когда набрав в грудь воздуха взалил на себя кусок разобраного трюмо и говорить было неудобно). К тому же дружбан мой возвращался домой чрез пол города в испачканом спорт-костюме, а у водилы разве что брюки сильнее помялись от сидения.
Вряд ли пример хороший, но... я старался :)
Добавлено через 10 минут
Блин, дописал, отправил и только потом до меня дошло: Вы наверное обиделись, на мой смайлик, подумав, что я о Вас написал... А я то думал, что Вас интересовал мой первый пост за сегодня. Я решил, что Вы меня подозреваеете в том, что яподлизываюсь к Wolsh`у...
На самом деле тот текстовый "смайл" был ответом на Ваш пост #117 (http://www.flasher.ru/forum/showpost.php?p=1148796&postcount=117). И значил он "Я хотел Вам ответить, но Wolsh меня опередил и дал развернутые объяснения, так что мне ничего не осталось, кроме как согласиться. А так, как Ваш вопрос был адресован мне, то не ответить, было бы неприлично."
Добавлено через 11 минут
А я всегда говорил, что общение смайлами невыразительное и сухое. Сам же на этом и попался :/
Akopalipsis
16.10.2013, 03:06
Вы наверное обиделись, на мой смайлик, подумав, что я о Вас написал...
я не капельки не обиделся, но да!) я принил их на свой счёт)) сорри)
И я не могу себе позволить не возвратится к теме - сегодняшний день худо - бедно да принёс плоды, очень рад, что напрямую указали, что наблюдатель, это тот же диспетчер. Сам я хоть и увидел схожесть, но не отказался бы от его использования только по тому, что ведь так в книжках написано. Но не могу я не спросить - это действительно так?
Потому что, получится, что много однотипных методов будут обработчиками. Например метод init, update, restart и т.п. будут обработчиками событий и ждать будут одноимённой константы. И при переносе этого класса в другое приложение обяжет использование тех же констант. Вроде не чего страшного, но если у всех классов есть слушатель restart, то придется делать констант для каждого класса.
Вот опытные используют слушателя или событиями кидаются?
elder_Nosferatu
16.10.2013, 05:22
Во первых ожидается не константа, а строка - будет она сохранена в константе, переменной или просто записана, как литерал - без разници. Так что если Вас напрягает писать Event.COMPLETE, то можете просто указать значение этой константы - "complete". Но эти константы не зря придумали. Помимо их прямого назначения, как констант, они еще несут в себе функцию подсказки. Если Ваш IDE поддержывает автозаполнение, тогда он Вам и подскажет точное название константы по первых буквах. Но если вместо константы вы будете набирать литерал "complete", тогда у Вас больше шансов сделать оЧЕПятку.
Еще в пользу констант. Обратите внимание на константы "родных" событий. Все они сохранены, как статические члены класса самого события, а значит используя это событие (читай импортируя класс события в приложение) Вы вместе с ним тянете и константы его типов. Так что не использовать эти константы просто глупо.
Также замечу, что заявленые константы типов никак не ограничивают набор возможных событий. Они носят только информативно-вспомогательный характер. Так что можно спокойно разослать событие класса Event с типом "oops_I_did_it_again". Беда только, что стороннему человеку будет сложно догадаться без подсказки, что такого события можно ожидать.
На счет личных событий. Если экземпляры Вашего класа хотят рассылать события, то не стоит спешить создавать для этого класса собственный класc событий. Можна использовать одно из стандартных событий. А если оно будет не достаточно информативным, тогда стоит создать свой класс события с необходимыми свойствами для хранения той инфы, которая должна передаваться с событем. Например универсальное событие Event. Его использует множество классов - события и сцены и редактирования текста и конец звука и смены кадров и т.д. и т.п. Но каким бы полезным не был класс Event, его информативности не хватает для клавиатуры. Вот для нее уже создали свое событие, которое предоставляет больше информации. Короче суть в том, что перед тем, как ваять свой класс события, следует думать не о том, кто его собирается рассылать, а о самом событии (не о классе, а о... явлении, что ли?). Хорошим примером будет MouseEvent. Его рассылает целая свора ИнтерактивныхОбъектов, но класс назвали не SpriteEvent, не ButtonEvent, не TextFieldEvent, и даже не InteractiveEvent, а MouseEvent. Интересно то, что класс Mouse (которому, по незнанию, можно было бы приписывать события класса MouseEvent) не наследует EventDispatcher, а значит его экземпляры и не могут рассылать события. Он вообще не имеет ничего полезного, кроме статических членов (его екземпляры ничем не будут отличаться от Object).
Упомяну еще две "хитрости". Полезного в них мало, но они помогут точнее понимать происходящее. Это как с Истиной. Человек, говоря Правду, расказывает Истину, но ставит акценты на то, что считает важным, тем самым уменьшает значение остального, превращая его в "тонкости" и "нюансы". Этим "грешат" все авторы, но...
Итак:
#1: Регистрируя обработчик события, EventDispatcher принимает ссылку на функцию. Никто не запрещает для нескольких событий использовать один обработчик. Для чего?
Вариант 1: когда я пишу класс кнопки, мне нужно запрограмировать ее поведение. Не знаю, как у кого а мои кнопки, будучи нажатымы, возвращаются в исходное положение, когда я их отпускаю и когда убираю с них курсор (даже если LMB все еще зажата). А значит я использую один обработчик для событий "mouseUp" и "rollOut".
Вариант 2: чтобы не плодить кучу методов-обработчиков я делаю все в одном единственном. Метод сомнительный, но возможность такая есть.
var btn:MyButton = MyButton();
btn.addEventListener(MouseEvent.CLICK, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_UP, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_DOWN, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_MOVE, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_OVER, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_OUT, mouseHandler);
function mouseHandler(event:MouseEvent):void {
switch (event.type) {
case MouseEvent.CLICK : /* do click */ break;
case MouseEvent.MOUSE_UP : /* do up */ break;
case MouseEvent.MOUSE_DOWN : /* do down */ break;
case MouseEvent.MOUSE_MOVE : /* do move */ break;
case MouseEvent.MOUSE_OVER : /* do over */ break;
case MouseEvent.MOUSE_OUT : /* do out */ break;
}
}
#2:Функция-обработчик ожыдает не столько экземпляр определенного класса, сколько какой-нибудь объект. Следовательно она справится с любым из наследников класса Object. Например, если Вас не интересуют детали события класса MouseEvent(ну там delta, altKey, ctrlKey, shiftKey, localX, stageY...), а всего лишь факт самого события, то в обработчике события можна запрашивать не MouseEvent, а его предка (Event или Object). Спросите "Зачем?" Я без понятия. Спросите "Сработает ли?" 100-пудово! Сам проверял.
var btn:MyButton = MyButton();
btn.addEventListener(MouseEvent.CLICK, clickHandler);
btn.addEventListener(MouseEvent.MOUSE_MOVE, moveHandler);
function clickHandler(event:Object):void {
trace("Oops...");
}
function moveHandler(event:Object):void {
trace("LOCAL POS:", event.localX + ", " + event.localY);
}
Все, пошел спать!
Akopalipsis
16.10.2013, 14:56
elder_Nosferatu Спасибо! Всё знал кроме последнего, возможно когда то пригодится.
А я пойду лазить в поисках информации об архитектуре, потому что как мне кажется, эта тема уже под грифом секретности.
Akopalipsis
16.10.2013, 18:13
Мне кажется ты не совсем понимаешь суть наследования.
требуется немного уточнения, Вы ведь так строите структуру?
То есть есть базовый абстрактный класс от которого наследуется главный класс одного из фигурантов MVC.
Так этот супер фигурант содержит ссылки на все суб классы, которые так же как и супер класс, наследуются от базового класса. А вот дети суб классов наследуются уже от кого хотят. Вы так делаете?
AlexLucas
16.10.2013, 18:51
Читаю и сразу же появляются вот такие ассоциации (http://habrastorage.org/storage2/c28/696/369/c286963692a52edd4042bad77c1b4180.jpg) :)
Akopalipsis
17.10.2013, 14:16
А у меня ассоциации, что я становлюсь, по неизвестной мне причине, очень невнимательный.
Мне уже в этой теме обьяснили, что я перепутал наследование с классом, который создает экземпляры.
Dukobpa3
17.10.2013, 16:01
Кривая диаграмма слегка.
На самом деле как-то так:
30107
Но МейнМодель и МейнВью могут создаваться в МейнКонтроллере.
На моей схеме они все втроем создаются в точке входа.
//UPD
Увидал косяк. В легенде перепутал супер с чилдом, там наоборот, стрелочка указывает в супер-класс. Картинку перерисовывать не буду сейчас.
Akopalipsis
17.10.2013, 16:13
Dukobpa3 смотря на Ваш график, мне кажется, что он в точности повторяет мой. Но смотря Ваш я понимаю причину своих незнаний, я main-m,v,c назвал супер. Но возможно что я и сейчас не понял, по этому уточню, у Вас от базового класса наследуются как главные mainClasses, так и узлы, которые создаются в mainClasses?
Dukobpa3
17.10.2013, 16:22
Базовый класс не умеет ничего кроме базовых механизмов.
Три базовых класса предоставляют уже налаженные связи между контроллером моделью и вью. Поэтому нигде не надо делать лишних подписок на события и в таком духе.
И всё что есть в проекте - наследуется от них, и соответственно уже имеют в себе унаследованные механизмы общения между м, в и ц.
Akopalipsis
17.10.2013, 16:44
Dukobpa3 Спасибо! Вот что ещё хочу уточнить. На перерисованном графике
отображена структура "чего то одного" ( контроллер, вью, или модель ). Предположим это вью и работа MainView
заключается только в создании, добавлении в ДОК и прочим, узловые вью, которые так же как и MainView унаследована от BaseView. Любой из NodeView являются как бы MainView для обьектов которые создаются в ней.
И вот эти обьекты, составляющие узловые классы, они тоже должны от BaseView наследоваться или же это уже не важно?
Dukobpa3
17.10.2013, 17:21
Ну если у дочерних объектов будут свои модели и прочие механизмы именно вью - то наследуйся.
Если не будет - то не наследуйся.
Akopalipsis
17.10.2013, 17:32
Опять немного проморгал слова - "И всё что есть в проекте - наследуется от них".
Но это от жуткой жажды быстрее все понять. И у меня ещё просьба - Вы не могли бы рассказать,
как организованна связь базовых классов и событийное обменивание. А то у меня просто пустота в том месте, где должны быть ответы на вопрос - как ( если смотреть на мой рисунок ) класс А может получить событие от модели о том, что пора поменять цвет, не подписавшись в самом классе А?
И скажите пожалуйста, у Вас есть один класс, как самый главный, который подменивает ключевых фигурантов? Что то типа контекста?
Dukobpa3
17.10.2013, 17:35
Нет. Не хочу и не могу. Сделай вконце концов нечто которое можно пощупать. А пальцем в небо в дальнейшем я объяснять отказываюсь ;)
Дальнейшее наше общение будет происходить следующим образом:
1. Делаешь проект на гитхабе.
2. Начинаешь что-то пилить.
3. Все свои вопросы сопровождаешь ссылками на нужный исходник.
4. Всё.
Добавлено через 34 секунды
Я готов помогать, но не так. Есть куча книг, которые приходится тупо цитировать. Утомляет.
Жалко что удалили картинку про сантехника :( Тему сисек раскрывала она...
Этот форум один из скучнейших
Dukobpa3
17.10.2013, 18:35
Флеш просто умер.
А вместе с ним и все мэтры слились с форума.
*тролфейс.жпг*
Добавлено через 34 секунды
*Многозначительным ностальгическим тоном* А вот в моё время..... Эхххх...
Akopalipsis
17.10.2013, 18:42
А вот в моё время..... Эхххх...
А что в Ваше время? Более жестоко смеялись над теми кто хотел научится?
Или разговоры о создании кнопок и синглтонов более интересно?)
Akopalipsis
17.10.2013, 18:43
Как по мне флешь не умирает, его убивают те кто на нём вырос.
У меня NodeView это класс-контейнер для коллекции классов виджетов, которые рендерят контейнер по xml нодам. Фабрика наделяет эту коллекцию интерфейсами ICore и IWidget
Добавлено через 1 минуту
флеш умер тогда когда перестал развиваться. Это ждет все не опенсорс фреймворки
Dukobpa3
17.10.2013, 19:16
В наше время кроме волша тут еще адекватные личности сидели.
И сидели более активно, а не по одному месаджу в неделю.
Добавлено через 31 секунду
Я пока не слился
А вас в список адекватных пока что никто и не записал ;)
я в списках не значусь - сам по себе метр.
Akopalipsis
17.10.2013, 20:50
У меня вопрос ко все кто практикует создавать классы не в контроллере.
Есть три режима MainMenu,Game и GameOver и следовательно три модели, вью и контроллера.
я согласен когда сказали, что в книге написано не верно по поводу ссылки на контроллер во вью, но
у меня тогда вот какое недопонимание. В момент запуска в классе Main в контроллер я передаю ссылку на MainView и после того, как MainView запустится, она узнает у модели, что состояние приложения находится в режиме MainMenu и поставит одноимённое представление. Но контроллер по прежнему имеет ссылку на MainView, как ему получить ссылку на currentView? Лезть во вью?
caseyryan
17.10.2013, 20:55
А зачем контроллеру получать ссылку на currentView? Ему как бы вообще должно быть пофиг) Он получил данные от модели, передал их вью, получил данные от вью, передал модели. Не важно какой там текущий вид, это сама вьюшка и должна решить в какую именно свою часть что затолкать
И сидели более активно, а не по одному месаджу в неделю.
Работа, дела, личная жизнь) На скольких форумах бывал, везде со временем наблюдалась подобная картина
сам по себе метр.
А я метр семьдесят пять) Шутка :D
elder_Nosferatu
18.10.2013, 04:08
Ну а я - метр восемдесят три. Чистая правда :)
А форум вянет - это факт. Но более всего страдает Флейм. Текущий же раздел живет-поживает. Правда от недостатка компетентной массовки интересные холивары прекратились, но...
К стати, по моему ряды форумчан поредели и после прекращения кармических манипуляций. Видать пошли искать новый инструмет прокачки ЧСВ.
Fogflasher
18.10.2013, 11:28
elder_Nosferatu, ого, кармических манипуляций )
То есть раньше на форуме за комменты добавляли некую карму?
Выходит, существовал особый персонаж с функциями архангела, который оценивал их полезность?
(сорри, не застал этих времен, но работы у него должно было быть полно, если это еще и модератор).
То есть раньше на форуме за комменты добавляли некую карму?
Выходит, существовал особый персонаж с функциями архангела, который оценивал их полезность?
Когда-то, над сообщениями существовала кнопка - сказать спасибо (что-то в этом духе). И так можно было благодарить, тем самым пополняя карму того человека. Было интересно (для меня).
Fogflasher
18.10.2013, 11:59
samana, аа точно, встречалось такое на других форумах.
Есть плюсы в таком подходе, но и минусы тоже.
Например, если в трэде много советующих, но TC раздаст карму только некоторым из них, то, соответственно, останутся обиженные за неполучение благодати. А если же TC всем одинаково карму добавляет, то это наоборот гасит мотивацию тех, кто расписывает всё в деталях, ибо тогда проще ограничиться общими фразами. И значит в трэде такого TC будет куча однострочных советов, лол.
Впрочем, возможно здесь всё было иначе, специфика конкретного форума тоже важна.
Psycho Tiger
18.10.2013, 13:05
Помню, Нильс очень ругался на слово "карма". А именно оно и прижилось :)
Где-то в англоязычном блоге я читал про выбор ЯП в качестве основного. Чувак перепробовал уйму всего и пришел к выводу, что лучший язык – это язык с развитым комьюнити. бОльшая часть as3 комьюнити – это (цитирую) "hello haw ar u haw to put mc in parent thx". И черт возьми, он прав. Здесь полно ребят из цитаты выше, некоторые "закаменели" в освоенных технологиях, в которых им более-менее комфортно, не желая делать/изучать что-нибудь новое, а если и изучают – сразу пихают туда что-нибудь известное, но никаким-боком-там-не-нужное, аргументируя что без xpath – никуда. Третьи вообще хвастаются когда-то написанным казино и приложением-таблицы-по-футболу, в адидасах с рынка рассказывая о красивой жизни добившегося успеха пацана. Конечно, здесь много хороших людей, но я говорю о том, что комьюнити не растёт. Число людей "уходящих" с флеша куда больше, чем приходящих.
Флеш умер 5-7 лет назад. Комьюнити и не будет расти, пока язык не станет ШИРОКИМ. Все что нужно знать во флеше, это как нарисовать кнопку на таймлайне и приципить ее кодом. Все остальное есть и в других языках. Здесь все погрязло на писании СВОИХ велосипедов, когда уже давно все пользуются только фреймворками оставляя своим безумным реализациям 5% времени. Все уже за вас написано, и явно написано лучше, на данном форуме например кроме wvxwv - никто не сможет достигнуть успехов, чтобы его фреймворки стали популярными и обсуждались миром, он может - вы нет.
Вопрос про рост комьюнити - это все равно, что разговорвать о смысле жизни.
Я бы конечно мог опуститься до оскорблений в сторону ПолосатойКошки, но нет смысла, он пока еще не дорос до уровня понятия, что он никто в мире программирования, как и 90% всех программистов, что он такая же офисная крыса как и все и не представляет из себя ничего. Но даже дело тут не в этом, это у него пройдет, кто то намного безболезненней пройдет этот путь, кто то так же. Итог один - люди в большенстве своем не будут лезть в дебри изучать Ядерный реактор, если их все устраивает на данный момент через parent.mc . Я совершенно точно так же могу сказать и о себе - я никто в программировании и я это понимаю, я не достиг и не достигну высот ученого или математика, я не буду двигать прогресс, даже работая в гугл или мейл - это все низший сорт. Дойти до среднего уровня работая в GameDev c компанией типа BioWare и т.п. - удостоятся единицы, и даже в этом случае прогресс не на из стороне, но эти люди могут сказать - мы достигли чего то в этой жизни. Поэтому комьюнити и не растет... тут долго можно обсуждать и говорить, но толку то от разговоров , никому ничего не надо. Между прочем еще одним критерием служит соверменный мир, его постулаты - он диктует , вы пишите.
Dukobpa3
18.10.2013, 15:37
в адидасах
Ты имел в виду абибос? :)
Я вот скучаю по карме. Помню славные времена когда инфокора минусовать можно было:) Да и вел он себя тогда потише:)
А я помню те времена , когда вас обоих не было. Псичотайгера я почему-то не помню. Молодой видно был еще. Больше молчал :)
Dukobpa3
18.10.2013, 15:46
Славные были времена:)
carrotoff
18.10.2013, 16:37
С кармой было хорошо, да. Я так и не понял, почему она пропала
Babylon разные времена были. Но дерзких все больше и больше с каждым годом, ну что поделать...
Добавлено через 1 минуту
С кармой было хорошо, да. Я так и не понял, почему она пропала Она пропала и проадает на многих ресурсах по одной простой причине - что многие новички и т.п. товарищи очень часто открыто просят их проплюсовать , дабы возгордиться, сам таким был, не спорю. А по скольку форумы нужны для решения вопросов, а не флейма - лишнюю систему убирают
Ну вот и за жизнь пошли разговоры, такое вот оно - mvc. ;)
in4core
Не будь тряпкой, 25 лет - не возраст для впадания в кризис среднего возраста. Где-то слышал, что человек до 30 только учиться, а после 30 - реализовывается.
carrotoff
С кармой было хорошо, да. Я так и не понял, почему она пропала
Инильс пытался сделать объективный профессиональный рейтинг, задумка не удалась.
carrotoff
18.10.2013, 17:28
Она пропала и проадает на многих ресурсах по одной простой причине - что многие новички и т.п. товарищи очень часто открыто просят их проплюсовать
Попробуй на хабре попросить плюсануть)
Инильс пытался сделать объективный профессиональный рейтинг, задумка не удалась.
Мне, кажется, было вполне неплохо. Правда в последнее время своего существования карма в диапазоне от 0 до 100 не говорила о человеке ровным счетом ничего.
in4core не 25, но дело тут не причем. Я оцениваю реальность как есть, в отличие от многих. После 30 люди тратят время на семью и детей, а не на реализацию, раньше надо было думать о реализации. Тем не менее , как бы это безысходно не звучало, ничего ни у кого из вас не изменится, покрайней мере пока вы будете разговаривать тут за жизнь, а не заниматься делом. Я между прочим заметил, что некая часть публики с форума слилась и погрузилась либо в реализации , либо бросили это дело совсем
Akopalipsis
18.10.2013, 18:49
Моё обьективное мнение, как новичка - дерзить кому то я даже в мыслях не когда не хотел,
пока не стал читать посты in4core, который, мало того
постоянно грязь льёт, так ещё задаёт тон остальным. Так везде, как одна "не оффисная крыса" заведется,
так и начинает растлевать весь коллектив. Если Вы вспоминаете, что раньше было хорошо, это только по тому, что к Вам так относились. Пример для меня только, это - Wolsh.
Он единственный, кто не жалеет код, да ещё тратит время на подробное обучение.
Что касается mvc - то тут как я понял все просто, одни получают удовольствие, от напоминания,
что есть MVC, а есть MVP, а другие... Не понятно что. По делу только Psycho Tiger помог и Wolsh. И это не чего личного. Не я тему начал, но мне хочется показать Вам,
как Вы выглядите в глазах новичков. Вы старожил так же видели?
Добавлено через 4 минуты
Если развить чуть дальше, то форум это место, где помогают, а не лайки зарабатываю.
Неужели Вы не помогаете из - за виртуальной циферки?
Добавлено через 4 минуты
Неужели есть люди, которые только из - за этого могут быть на форуме?
Добавлено через 41 минуту
И как мне кажется, форум меня немного изменил, изменил моё отношение к людям.
Но это скорее всего по тому, что в начале мне попадались, только те, кто уже давно на форуме и воспитан на хороших отношения. Статистика просмотра говорит, что о mvc хотели узнать 2000.. а помочь новичку в проблеме с текстом, это не интересно..
Psycho Tiger
18.10.2013, 21:39
на данном форуме например кроме wvxwv - никто не сможет достигнуть успехов, чтобы его фреймворки стали популярными и обсуждались миром, он может - вы нет.
...и после этих слов Дембицкий с Джоном спились.
Zebestov
18.10.2013, 22:04
...и после этих слов Дембицкий с Джоном спились.
…у Блада
Akopalipsis, очень плохо, что вы ждете помощи от уолша или пт и имитируйте свои собственные поиски решения.
Добавлено через 1 минуту
…у Блада
Во память у чела.
Akopalipsis
19.10.2013, 01:39
Babylon это не так! я возможно не правильно сказал и извиняюсь, если кому то показалось резкими мои слова. я имел ввиду что столько времени и строчек текста уходит для спора и обьяснения MVC, как такового не существующего. Ведь это не паттерн, а архитектура, почему не кто не говорит о правильной реализации, но спорят, кто кого создаёт. Не возможно не согласится, что минимальный пример Psycho Tiger может заменить все коменты на форуме, которые в части являются комментариями к его статьям. Так же не возможно не согласится, что лучше раз посмотреть на реализацию, чем читать целую библиотеку, которая ещё и не факт что правильно подскажет. Можно перекопать все два или три фраймворка, честно сказать я полез в RL и даже кое что, ( что возможно я понял по своему ) я когда то сделаю. Но я только посмотрел и закрыл, потому что учится и делать фраймвор скопировав уже имеющийся я не хочу. Меня вчера осинило и я сейчас делаю и проверяю, как доделаю обязательно покажу чтобы сказали, что так делать нельзя. И возможно меня тоже не поймут как и Вас)) У Вас ядро, а у меня абстракции будут))
Babylon пора валить на жабу, нечего тут делать
инфокор, Вы прямо читаете мои мысли :)
Akopalipsis
21.10.2013, 02:25
Про ссылку на контроллер это нормально, это один из вариантов реализации, когда Вью не посылает события контроллеру, а вызывает его методы напрямую. Для толстых контроллеров это недопустимо, но тонкие пишутся специально для конкретных Вью, и такой способ возможен.
Wolsh я всё это время читаю и читаю. И у меня появился вопрос лично к Вам, кто единственный не отвергает ссылку на контроллер во вью, но сначала мысли..
Во всех статьях, во всех книгах, написано - вью содержит ссылку на контроллер. И отрицая эту теорию я незаметно для себя, в мыслях пришёл к ней же. Вот есть у меня мир, который руководится своими контроллерами и моделями. И вдруг я добавляю персонажа в этот мир. Первое что приходит на ум, слушать вью на добавление и передавать это в контроллер мира. Там единственное что можно извлечь, это таргет-вью персонажа у которой есть ссылки.
Но у меня вопрос - как делаете ВЫ?
Добавлено через 21 минуту
Вот я опять написал и только сейчас понял, что ерунду.
Akopalipsis - Вольш делает так же как и все, не держит ссылку на контроллер во вью. Ссылку на контрол деражать , значит лень лишний раз создать событие во вьюхе. Держат ссыль для того, чтобы сразу дергать контрол. Это не очень грамотно, но по сути имеет место быть...
Да просто не раз попадались предложения не лукавить и делать напрямую. Признать, что на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью. И что разнесение их с помощью Событий звучит красиво, пока рассматривается пример с одним кликом по кнопке. Но в случае игры появляется 100500 уникальных типов событий, к тому же несущих в себе данные, и ежу понятно что Вью, посылая событие, рассчитывает на реакцию, а Контроллер обязан знать именно этот конкретный тип события, что хочешь-не хочешь а создает сильную связанность Вью и "его"(!) Контроллера и плодит бесконечные классы Событий, иногда описывающих одно-единственное действие во Вью. И как альтернатива предлагается отказаться от Событий между Вью и Контроллером, заменив ОБЩИЙ СПИСОК событий Интерфейсом Контроллера, дергая его методы напрямую. То есть Вью "ожидает" весьма конкретный контроллер, понимающий все задачи Вью. И я склонен соглашаться, что иногда в конкретных проектах в этом нет ничего дурного. Очень радует фраза GoF в их книге о паттернах, когда они рассказывают концепцию MVC в начале книги и приводят Схему MVC с примечанием: "на Схеме не показаны Контроллеры для простоты понимания". Вот как-то так. Контроллер — всего лишь придаток Вью, собирающий в одном месте, удобном для редактирования, логику взаимодействия Вью с Моделью, позволяя в собственно Вью сконцентрироваться только на визуалке. Этакий набор методов Вью для дерганья Модели, чем по сути контроллер и является.
Akopalipsis
21.10.2013, 15:02
В день я раз по двадцать переписываю всё с начала и не как не могу найти хотя бы простое решение реализации. Но мне очень бы помог совет опытных - предположим, есть главное окно приложения, оно контролируется главными mvc. Есть два окошка, одно показывает минуты, а другое секунды. Собраны эти окошки тоже по mvc, то есть у каждого окошка своя модель, вью и контроллер. Добавляются они естественно во вью, но как, у этих окошек точкой входа в главное приложение будет их класс Main?
Psycho Tiger
21.10.2013, 15:45
Ну, контроллер должен уметь добавлять вью в общий дисплайлист.
По идее, раз тут зеркальное отображение модель - вью, то выглядит это так:
1) Создается главная тройка.
2) В модель вкладывается другая модель (по-сути это addChild). После вложение диспатчится событие ADDED.
3) Главная вью ловит событие ADDED и видит: ага, да это же секундомер. Сама создаёт вью секундомера и даёт ему модель.
4) Контроллер, попивая коктейльчики, отдыхает.
P.S. на днях постараюсь опубликовать 3 часть статьи, там как раз схожий пример.
Akopalipsis
21.10.2013, 16:16
Psycho Tiger пусть я буду выглядеть невежей, но я сразу перейду к - долгожданному продолжению!) я скажу, что я бы хотел подчерпнуть из Вашей статьи и я уверен, что не я один этого хочу:
1) Во всех примерах ( в Ваших, в книгах ) всегда показывают на минимальном примере, всех по одному.
И по этому очень хотелось бы видеть, как устроена архитектура, когда все фигурантов минимум три.
я уже две недели не могу сделать вот что - я ставлю себе задачей сделать
MainMenuView,GameView,GameOverView.
MainMenuModel,GameModel,GameOverModel.
MainMenuController,GameController,GameOverController.
Соответственно ( я могу ошибаться ) есть базовые фигуранты и главные фигуранты - MainModel, MainView и MainController, которые наследуются от своих базовых классов и создают в себе все классы, которые я перечислил выше. То есть без графики без всего, просто минимум, но у меня не получается полноценно передавать ссылки. я не прошу всё делать так как Вы все делаете в жизни, мега секретные парсеры массивов или что то ещё, не надо. Но если можете сделайте максимально возможную архитектуру приближенную к реальности.
2) Отдельным пунктом хочется попросить сделать максимально приближенным к жизни, инициализацию
всей цепочки, в жизни же MVC это архитектура состоящая из других паттернов, вот её и хотелось бы увидеть.
И даже ненужно поэзии и каких то видов, квадратики вполне подойдут.
И Спасибо Вам!
Dukobpa3
21.10.2013, 17:22
на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью.
Ну не соглашусь.....
Вернее вроде бы и соглашусь, но как-то коробит от такого.
И чтоб в моих проектах такой фигни не встречалось я просто добавил класс медиатора.
Итого на весь проект получается:
- штуки 4-10 контроллеров.
- много моделей (два дерева моделей)
- много вьюх
- медиаторов примерно в три пять-раз меньше вьюх.
Вью диспатчит не в контроллер а в медиатор, и медиатор умеет слушать не СВОЮ вью, а СВОЙ ВИД вью.
Например медиатор окон, медиатор попапов.
И потом уже медиатор, заворачивает событие вью в какую-то абстракцию и шлет контроллеру(ам), может и на сервер послать, если это не требует логик. (Ну как в магазине кнопка купить, тут просто запрос отослать надо. Никаких даже проверок, так как проверки раньше сделаны в модели, и раз уж пользователь смог нажать кнопку - значит ему это позволили сделать).
Короче дополнительный слой абстракции упростил понимание системы и очистил паку *****кода и хардкода в контроллерах.
Обработка в медиаторе выглядит как достаточно большой свич действий от своих вьюх, по возможности стараюсь абстрагировать это как могу.
Dukobpa3 - с такой архитектурой сразу ставьте крест на своей карьере программиста. Такой код не только читать, его самому сложно понять. Это очередные извращения. Почему не делать все просто? Ведь простота залог успеха. Если приложение не сильно большое достаточно 1-2х контроллов, много моделей(если надо) и вьюх. Вот к примеру, я как то делал слот автоматы, думаю не стоит объяснять что это.
1 основной контроллер для захвата сервера, запрос-ответ, все просто. Основная вьюха при спине делает запрос, контрол лезет на сервер отдает значение модели, основная вьюха и сопутсвующие ей подхватывают от моделей то, что нужно. Это читабельно и понято - это чистый приятный MVC. Далее создаем еще один контрол, для связи видов GUI . Вид с линиями и вид с кнопочками, они пересекаются между собой, поэтому контрол там очень кстати. Все. удобно и хорошо. При этом я не могу сказать, что это МАЛЕНЬКОЕ приложение, оно довольно приличное.
В вашем же случае подход может быть оправдан наверное к примеру, в приложении аналога фотошопа с сервером. Хотя тоже извращение.
Я сетую и буду сетовать и призывать всех здравомыслящих людей пользоваться pure - ибо это читабельно , понятно, и просто в доработке.
Опять же никто не скажет какой путь верный для конкретного проекта, путей много. Но сколько бы разных проектов я не делал, и переписывал их по 100 раз, как начинающий Akopalipsis, дабы найти нирвану, и в итоге какой бы проект я сейчас не делал - пуре спасает и еще ни разу, я не поймал себя на мысли, что я сделал криво, и можно было бы лучше, после того, как я перешел на чистый.
Dukobpa3
21.10.2013, 18:15
ставьте крест на своей карьере программиста
лол) ок)
Только я сейчас синьор дев + мид архитект в топовой(три месяца назад перегнали зингу по баблу:)) конторе пишущей для ФБ.
И боюсь те проекты которые я пишу - ты даже собрать не сможешь:)
//*****************
Но про крест на карьере программиста уже и сам задумываюсь)) Открою барчик вон как блад) Буду к пиву ближе и к людям:) А то всё код да код) Скучно стало жить.
Добавлено через 4 минуты
И да. про пурмвц я могу много рассказать:)
Это просто инструмент, и писать на нем неадекват очень легко:)
Хотя во многих случаях это лучше чем свои велосипеды банально потому что вся компания "почти одинаково" пишет(на практике это нифига не так получается).
Добавлено через 5 минут
Если вы не видели последовательного екстенда команды с оверрайдом екзекьюта - вы не видели пурмвц в действии:))))))))
(Я когда первый раз увидел - испугался:) теперь привык, просто ржу:))
Добавлено через 11 минут
я не поймал себя на мысли, что я сделал криво
Вот зря:)
Dukobpa3 - пуре МВС не имеется ввиду фреймворк. А имеется ввиду своя реализация , основанная на четких постулатах MVC.
*Только я сейчас синьор дев + мид архитект* Я готов с тобой поспорить , ты работаешь с 8(9-10) до 6(7-8) сидя в офисе целый день. А я работаю когда захочу и сколько захочу, при этом ЗП у меня выше или равна вашей :) привет :)
Я даже больше скажу, любой лось может устроится в топовую компанию типа mail.ru легко и непринужденно. Отпахать там на дядю пару лет и выбиться в тим лиды например. Этим уже никого не удивишь. Очень часто, тем более сейчас стало можно, брать средней руки программиста, обучить и т.п. Топовая компания это Samsung например, или из веб Google. Вы работаете в одной из них и вас ценят как лучшего работника? Если так, я преклоняюсь перед вами :)
P.s. про бар хорошая идея, только боюсь ваших ЗП не хватит , чтобы его открыть, содержать, и развивать. Хотя да, щас же кредит есть, так о чем это мы ... ах да о программировании
Dukobpa3
21.10.2013, 18:48
Я готов с тобой поспорить
Вот поспорить ты всегда готов, в этом никто не сомневается. Только, не факт, что аргументы адекватные в этих спорах будут:)
Ну как же, аргументы на лицо. Приведены выше, что такое топовая компания, и чем отличается работа в офисе от свободного заработка. Ну дело не в этом. Я же говорю со своей колокольни, и я понимаю о чем я говорю, я программирую наверное побольше чем ты, хотя может и меньше, не суть, опыт у меня довольно богатый в этом. То, что я многого не знаю - я не отрицаю, я например никогда не работал с 3д и не буду комментировать это, дабы не знаю о чем речь вести. А вот про архитектуру я могу спорить, дабы этот опыт есть у всех и у всех он свой, со своей стороны я ответил - чистый МВС , как написано в справке - по моему мнению самый удобоваримый паттерн во всех направлениях, что в больших, что в малых проектах. Да бы на данный момент я не чуствую нужды переписвать проекты по 100 раз, как мне хотелось это ранее ища лучшее решение.
И да, простите, никаких оскраблений, просто не удержусь. Как Задорнов про Мерчендайзеров* говорил, синьор дев - синьор Помидор! Вот кто! Просто эти современные названия настолько смешно звучат, что ужас, при этом они не говорят ничего толкового. Я бы просто назвал разработчик ПО или разработчик ИГР. Это понятно и вопросов не возникает.
Akopalipsis
21.10.2013, 19:06
Когда начинаешь кодить, то первые советы, это - не использовать array.length в цикле, а выносить за пределы.
И ты начинаешь понимать, почему это так и вспоминаешь полученный совет каждый раз, когда берешься что то делать. Когда говорят, что MVC это просто, это не правда. Просто - это ( наверное ) когда мало кода.
Когда его будет много, то я даже сейчас понимаю, что эта ( стандартная ) модель не выдержит.
Пока я не найду и не пойму принцип, я не буду пользоваться фраймворками.
Но уже сейчас я понимаю, что будь то квадратик или персонаж, у каждого вида, взаимодействующего с моделью, должен быть свой контроллер. Как обьединить все эти множества контроллеров в одном месте,
я пока не знаю, но мне кажется, что медиаторы описанные Dukobpa3'зом это более опытное решение, моих тысячи контроллеров. И я не знаю как в Pure, но в RL вроде бы все построено через десятки посредников. я надеюсь на Psycho Tiger, потому что тогда останется только два варианта - делать и не заморачиваться о правильности и смотреть в будущие с тоской, потому что, даже пусть я сотни игр сделаю "неправильно", правильность не появится, а лишь будут удалятся. И второй вариант, читать и пробовать, пробовать и ещё раз пробовать, хоть полгода.
Но зато это не испортит сознание и не направит в ненужное русло, что ещё больше выжжет в мозгу "неправильность". И разные могут быть коды для инвентаря и для меню, но не для MVC. И пусть у меня нет знаний, но я в этом уверен.
Psycho Tiger
21.10.2013, 19:09
Dukobpa3 - с такой архитектурой сразу ставьте крест на своей карьере программиста.
http://img4.joyreactor.cc/pics/post/%D1%80%D0%B0%D0%B4%D0%BE%D1%81%D1%82%D1%8C-%D0%BA%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%B3%D0%B8%D1%84%D0%BA%D0%B8-%D0%BF%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0-113114.gif
array.length Используй в цикле на здоровье. Об этом говорят на будущее, когда будут большие циклы или рантайм пробежки, дабы хоть чем то оптимизировать. А вообще пофиг, скорость не падает от этого при циклах 0-100. А если циклы больше, тогда можно конечно и оптимизировать.
Но уже сейчас я понимаю, что будь то квадратик или персонаж, у каждого вида, взаимодействующего с моделью, должен быть свой контроллер. Да нет же блин! Ну не понимаете Вы пока ничего. Я не пойму откуда ноги растут! Контроллер нужен там, где он НУЖЕН! А вот где он нужен диктует приложение.
ТС - давай те так. Вы напишите приложение какое нибудь маленькое и выложите весь код и задатите вопросы. Вам подскажут где и как стоило бы изменить. Пока что Вы говорите - космическую ерунуд, без обид.
Добавлено через 1 минуту
Psycho Tiger надеюсь не удалят. хоть чем то разбавить столь скушное действо.
Psycho Tiger
21.10.2013, 19:38
*Только я сейчас синьор дев + мид архитект* Я готов с тобой поспорить...
... ведь я, in4core, знаю всё и всех могу переспорить. Я могу даже переспорить тебя в том, где и кем ты работаешь.
...ты работаешь с 8(9-10) до 6(7-8) сидя в офисе целый день. А я работаю когда захочу и сколько захочу...
... потому что живу с родителями и могу попросить 100 рублей на обед у мамы.
при этом ЗП у меня выше или равна вашей
Здесь ЗП, наверное, это "Задний Проход".
...Я даже больше скажу, любой лось может устроится в топовую компанию типа mail.ru легко и непринужденно...
...и именно поэтому я там не работаю, а не потому что меня не взяли.
Отпахать там на дядю пару лет и выбиться в тим лиды например. Этим уже никого не удивишь.
Другое дело Я!: написал слот-автомат, например.
P.s. про бар хорошая идея, только боюсь ваших ЗП не хватит , чтобы его открыть, содержать, и развивать.
(Обычно, любое заведение открывается для получения прибыли, а не для растраты личных средств на содержание/развитие. Скорее всего, здесь опять была отсылка к чердаку).
Сашка, самое смешное даже не то, что ты пытаешься учить-поучать людей, у которых совсем недавно сам спрашивал "а как такое сделать". Самое смешное что ты вроде-бы-олигарх, а куришь винстон и носишь самую дешевую модель найков которая ещё и смотрится ущербно, потому что подделка.
Psycho Tiger - кто тебе сказал что я курю винстон вопервых, во вторых , что я ношу? У меня вообще то вся одежда на данный момент либо из франции либо из италии, именно там купленная. А что на фотках старых было, так там я еще совсем молодой был. И живу я уже давно один.
Я в какой раз убеждаюсь, что у тебя проблемы личностного характера, то ли тебя в детстве били, то ли до сих пор, то ли семья у тебя не благополучная, непонятно. Дабы рассуждать кто в чем одет, кто что покупает и почему, это по-моему низ маргинальности душевной именно. Меня это ни капли не заденет, даже если я буду ходить в рваных носках и штанах, ничего от этого не изменится и таких как ты я буду поучать всегда.
Psycho Tiger
21.10.2013, 20:10
Дабы рассуждать кто в чем одет, кто что покупает и почему, это по-моему низ маргинальности душевной именно.
Ты открыто рассказываешь не к месту как ты успешен, хотя всем, в общем-то, плевать. При этом одеваешься исключительно безвкусно в самые дешевые бренды, выбранные, безусловно, по ценовому сегменту. Ты ведь не глупый, чтобы не увидеть здесь четкой логической связи? )
даже если я буду ходить в рваных носках и штанах, ничего от этого не изменится и таких как ты я буду поучать всегда.
Однажды гуляя я подкинул мелочи какому-то бродяге, ночевавшему на асфальте. Он тоже хотел мне рассказать о жизни. Я что, магнит для историй? :)
Мораль-то в том, что на техническом форуме общение происходит между людьми по техническим вопросам. Никому нет дела до твоих окладов, твоей жизни, твоего бойфренда. Профессиональные навыки здесь подчерпывают из сообщений, с них же строится какой-то авторитет участников. Рассказы о твоих окладах / успехе с МММ авторитета тебе не дадут; даст успех твой опыт – теперь я не сомневаюсь в твоих возможностях в создании слот-автоматов.
Akopalipsis
21.10.2013, 20:23
Хватит говорить о глупостях! Не отвлекайте Psycho Tiger'а!)
Dukobpa3
21.10.2013, 20:25
я не сомневаюсь в твоих возможностях в создании слот-автоматов.
А я сомневаюсь...:)
Но не в слотах ведь счастье и не в заливке сцены одним шейпом)
Ты открыто рассказываешь не к месту как ты успешен, хотя всем, в общем-то, плевать. Дело в том, что я не рассказываю никому ничего. Точнее я с этого не начинаю. Каждый мой комментарий начинается со слов, что я разрабатывал данное приложение, а соотвественно имею опыт. А не со слов, что я успешен, а вы никто. В данном случае начал говорить об успешности Du3 - я ему ответил, что он не прав.
Ты ведь не глупый, чтобы не увидеть здесь четкой логической связи? )
Ни капли не вижу. Достаток не зависит от того, как человек одевается. Ни один уважающий себя миллиардер не будет работать на публику. Это закон. Ему нечего никому доказывать. Я конечно не миллиардер, но придерживаюсь точно такой же точки зрения, например. Кроме того, ты кто такой, чтобы судить о вкусах? Может известный кутюрье? .. ах да про кутюрье
а) Здесь ЗП, наверное, это "Задний Проход".
, твоего бойфренда.
Я уже какой раз подчеркиваю о твоих гейских замашках. Нам пофигу, что ты являешься элитой нетрадиционной ориентации, видимо поэтому тебя и шмотки сильно беспокоят. Обидно за нацию, что п становится слишком много.
А так да, конечно ты прав - это же технический форум и тут по ответам судят. Только я смотрю , что ты не отвечаешь, а со мной споришь в теме про MVC - кто что одевает
Добавлено через 34 секунды
А я сомневаюсь... Очень зря. 100+ игр разработано и активно используются.
alexcon314
21.10.2013, 21:57
Финита.
Но то, что скука смертная - это да.
а просто не раз попадались предложения не лукавить и делать напрямую. Признать, что на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью. И что разнесение их с помощью Событий звучит красиво, пока рассматривается пример с одним кликом по кнопке. Но в случае игры появляется 100500 уникальных типов событий, к тому же несущих в себе данные, и ежу понятно что Вью, посылая событие, рассчитывает на реакцию, а Контроллер обязан знать именно этот конкретный тип события, что хочешь-не хочешь а создает сильную связанность Вью и "его"(!) Контроллера и плодит бесконечные классы Событий, иногда описывающих одно-единственное действие во Вью. И как альтернатива предлагается отказаться от Событий между Вью и Контроллером, заменив ОБЩИЙ СПИСОК событий Интерфейсом Контроллера, дергая его методы напрямую. То есть Вью "ожидает" весьма конкретный контроллер, понимающий все задачи Вью. И я склонен соглашаться, что иногда в конкретных проектах в этом нет ничего дурного. Очень радует фраза GoF в их книге о паттернах, когда они рассказывают концепцию MVC в начале книги и приводят Схему MVC с примечанием: "на Схеме не показаны Контроллеры для простоты понимания". Вот как-то так. Контроллер — всего лишь придаток Вью, собирающий в одном месте, удобном для редактирования, логику взаимодействия Вью с Моделью, позволяя в собственно Вью сконцентрироваться только на визуалке. Этакий набор методов Вью для дерганья Модели, чем по сути контроллер и является.
И чтоб в моих проектах такой фигни не встречалось я просто добавил класс медиатора.
Wolsh, Дюк, именно, эта схема описывается в MVVM или PresentationModel (по Фаулеру)
PS. не увидел, что тема уже закрыта.
удаляюсь.
Не, я требую продолжения банкета! Почки один раз царице!
Почки царице - больше одной почки никак не получится.
Но давай продолжим.
Давайте лучше обсудим подходы и разницы между PM, MVVM и концепцией медиаторов принятых в робоногах и пуреМВЦ.
Также, давайте затронем тему иерархической МВЦ и способов инжектирования зависимостей.
Да и просто принципы Инверсии управления.
Dukobpa3
31.10.2013, 00:10
Нравится:
1. Пюре и РЛ - нравится синглтоновый подход, ибо он оправдан в большинстве своем. Все элементы системы предполагаются в одном екземпляре. Манагеры для быстрого доступа к этим элементам системы.
2. РЛ - нравится инверсия контроля, инициализация не деревом а отдельным неким манагером, себе похожую сделал.
Не нравится:
1. пюре - олбсервер с одной шиной, могу из контроллера послеть в модель, хотя зачем. Так же из модели могу послать команду, вырвиглазие получается.
2. пюре - если работать одному или 2-3 человека с грамотным лидом - глобальный синглотоновый домступ круто, ибо легко контролировать не отклоняясь от идеалогии. В болшой команде очень легко выстрелить себе в ногу, поэтому сам вполне таки подходы одобряю, в ентерпрайзе ни-ни. Надо делать нечто более ограниченное и зашоренное.
3. То же что и в п.2 относится и к РЛ.
А вцелом то че. Любой инструмент просто инструмент. Главное как им пользоваться. И из пюре реально конфетку собрать со всеми его глобальными обсервера и синглтонами. Только надо понимать зачем.
//*******************
еще:
Люблю одноуровневые модели. Если дерево - то уже чуть другая структура полдучается. На одном уровне модели. а потом внутри каждой еще какие-то структурки есть, но эти структурки по сути уже не модели с точки зрения какого-либо фреймворка, это просто группы данных.
Вообще не одобряю дерево контроллеров. Если допустим вью и модели можно сделать как два зеркальных взаимодополняющих дерева - это круто.
А вот контроллеры в деревья складывать вообще не понимаю зачем, хотя видел такие реализации.
Ненавижу паттерн команда, как в пюре. Там где должен быть контроллер - там лучше юзать контроллер. Весь проект на командах это неуправляемая опа. Зато люблю использовать этот паттерн в месте общения с сервером. Если с сервера прилетела команда - то вполне логично сделать ее командой. Чтоб сама себя и выполнить могла. РПЦ в чистом виде. В любых других реализациях хз. Готов спорить.
Wolsh, Дюк, именно, эта схема описывается в MVVM или PresentationModel (по Фаулеру)А, вот где я это видел)))
Мне, признаться, не очень понятны медиаторы. То есть когда читаешь (у тех же GoF, например), теоретически все понятно. Но на практике применить не удалось (может, не очень хотелось). Было бы интересно разобрать какой-то минимальный практический пример, хотя бы на словах (ибо понимаю, что кода будет несколько классов).
Akopalipsis
31.10.2013, 00:15
Давайте лучше обсудим подходы и разницы между PM, MVVM и концепцией медиаторов принятых в робоногах и пуреМВЦ.
Почему то мне кажется, что ЭТИ моменты будут скучны... Это же про них надо читать..
А если кто и прочёл, то он подумает, а зачем мне надо рассказывать... Я ЖЕ ЧИТАЛ!
А вот если по теме, то как было сказано ранее, если я правильно понял, то MVVM - это ссылка на контроллер во вью. Вот как я это вижу - одни прелести, на каждый вид своя маленькая моделька и свой маленький контроллер. Главная модель становится создателем маленьких моделей, после создания диспатчит события главной вью. Та создает маленький вид и при добавлении на стейдж активирует свой маленький контроллер. Как мне кажется, такой вариант, оставляем меньше шансов сделать что то "Толстое" и легко редактировать и заменять.
Добавлено через 31 секунду
Попёрло!!!)
Akopalipsis - не нужно вам ничего видеть, вам нужно писать. Сразу оговорюсь - когда первый раз начал разюирать МВС - сразу же попался мне пример с ссылкой на контроллер, причем даже приложение было целое, было можно и поковыряться. И по началу я тоже подмывал - неплхая штука. Со временем забудите как страшный сон, но только когда напишите одно приложение ТАК, а другое как положено. Руки захотят добра. Да и вообще по сути, в простеньких приложениях задумываться об контроллерах редко приходится, как пишет Дикобраз - на один раз и забыл о них. - ну так оно и есть
Akopalipsis
31.10.2013, 00:26
in4core я не спорю, я просто говорю то, что кручу в голове, чего мне пока не хватает. Хоть я и делаю первое "нечто" ( дошёл до анимации ), то уже сейчас хочу вот что сказать, обсервер - обсервером, но мне почему то в голову идёт переделать немного EventDispatcher так, чтобы классы были в виде обычных, чтобы они не были зависимы от конкретного приложения. Так же мне хочется использовать для удобства "красивые константы", но тогда получится, что единственный контроллер утонет после моего сумашедстви и я в нем запутаюсь. А так, у меня грубоГоворя, папка_кнопка и я знаю, что в ней и вид и контроллер и если надо моделька...
чтобы они не были зависимы от конкретного приложения Ура! наконец то вы дошли до понятия совершенный код и идеальный велосипед! Срочно бросайте эти экстремистские забавы - пока совсем плохо не стало
Dukobpa3
31.10.2013, 03:45
Мне, признаться, не очень понятны медиаторы.
А в чем конкретно вопросы и что не понятно на практике?
Медиаторы становятся понятными когда используется тяжелая составная вью. Например какая-то изометрическая карта города.
Тогда удобнее сделать несколько вьюх, и все их объединить одним медиатором. Банально улучшается управляемость кода, классы меньше и лучше инкапсулированы. Но это возможно не совсем удачный пример так как его можно разрулить и просто грамотной организацией самой вьюхи.
Или второй хороший пример когда есть набор одинаковых вьюх. Тогда управление ими вынести в медиатор. Например какой-то медиатор окон или попапов. Попапов много, но с точки зрения системы - сущность одна, и это медиатор.
Еще один бонус медиатора в том что вьюхи еще тупее и еще легче заменяемые.
С точки зрения системы - вью - это медиатор. А собственно вью - это просто арт (какой-то подгружаемый мувик, например).
С таким подходом круто делать скинуемые системы. Но не в том плане скинуемые что просто шкурку поменять, а более наворочанные.
Как в каком-то казино слотмашины - игра одна, игровая логика у всех машин одинаковая, но самих машин много, и все они чем-то да отличаются, уже в понятие скину не вписывается, просто шкуркой не обойдешься. И вот эти отличия между машинами сглаживает медиатор, либо набор медиаторов.
А система этого всего не видит. Она видит только медиатор.
//********************
Это примеры из моей практики, либо, как с изометрической картой - проблемы, с которыми столкнулся, но на тот момент решил кривовато, ибо не догадался использовать медиатор.
Я не использую понятие медиатор, у меня вью это иерархическая структура, состоящая из контейнеров, которые заполняются виджетами. Виджет ничем не заполняется - это терминальный визуальный элемент
Команда формирует XPath запрос, который вырезает нужную структуру из иерархии видов. Для этого нужен XML.
Dukobpa3
31.10.2013, 05:31
терминальный
Терминал? Это который bash, cmd, powershell?
Psycho Tiger
31.10.2013, 11:19
Терминал? Это который bash, cmd, powershell?
Это по научному так называют "конечный".
Команда формирует XPath запрос, который вырезает нужную структуру из иерархии видов. Для этого нужен XML.
Решение приятное и, возможно, единственное, если в фреймворк добавлять e2e тестирование.
Но зачем тащить с собой XML? Чтобы перевозить апельсины нужна ёмкость – бочки?
Иерархию, конечно, можно и на Обжектах строить)) Однако у них то нет такой плюшки как XPath/e4x.
Dukobpa3
31.10.2013, 12:15
Ябпосмотрел.
А то смущает меня прозрачная вью, вывернутая наизнанку по отношению к системе.
Но, в целом, теперь понятно что такое XML-MVC. Если еще и модели зеркальное дерево имеют - то вполне удобно должно быть.
Добавлено через 12 минут
А, ну да.
Еще и новое слово выучил
Это по научному так называют "конечный".
Вот как хорошо что не иссякли темы про мвц:)
В них всесторонне развиваешься:)
Dukobpa3, а можно поконкретней про медиаторы?))
"для всей системы Вью это медиатор" — для какой системы? Для кучки растерявшихся контроллеров?
Можно ли [выдумать] какой-то простой пример, типа "есть два таких-то Вью, есть два контроллера. И вот возникает такая ситуация /*описание ситуации*/. Тогда мы вводим медиатор, который регистрирует контроллеры и вьюхи, и /*описание действий медиатора*/.
Желательно, чтоб было понятно не только мне, но и другим всесторонне развивающимся))
Dukobpa3
31.10.2013, 13:31
для какой системы?
В моем понимании система это и есть наша программа.
Некий уровень абстракции, на котором нам не интересна конкретная кнопка во вью, или конкретный чекер в модели. На этом уровне абстракции нам больше интересны модули вцелом и их апи, которым они повернуты друг к другу. Можем принять что модули, с этой точки зрения - набор одноуровневых блоков (моделей, контроллеров, вью).
А про медиаторы я тут только что много чего-то написал, но так написал что и сам бы не понял. Решил не отправлять. Я подумаю как сформулировать и позже повторный заход сделаю.
Добавлено через 22 минуты
А вообще меня уже конкретно припарил мвц.
Изначально мне нравилось потому что у меня были контроллеры, которые инитят свои модели и свои вьюхи. Получалось модуль - это по сути контроллер, а что там внутри него - уже мало кого волнует, он там сам в себе рулил делами с моделями и вью.
Потом я столкнулся с тем что в некоторых местах надо чтоб к одной модели был доступ у парочки контроллеров. Или к одной модели подписаны несколько вьюх, которые в разных контроллерах.
Так из контроллера ушла инициализация вьюх и моделей. Получилось три разных плоскости для моделей вью и контроллеров, внутри каждой из плоскостей все объекты одноуровневые (как в РЛ). Но я продолжал воспринимать понятие модуля как контроллер. Хотя это уже больше на граф похожу из трех видов узлов.
Теперь вроде и четкого мвц не осталось, вроде и удобнее чем было. И грубо говоря на всю систему осталась одна вью, одна модель и один контроллер (пусть они и выглядят как коллекция из структур а не одна структура, но мы ведь в большинстве случаев можем на это забить). Разделение ролей между вью, моделями и контроллерами четкое. Это круто, но это уже не тот мвц с которого всё начиналось.
И теперь уже мысли может нафиг это надо и проще ведь можно.
Чувствую скоро забью на все паттерны и пойду функциональщину на петоне клепать.
Добавлено через 2 часа 46 минут
Про медиатор я не знаю как объяснить:)
Я могу процитировать гофов или еще кого.
Но если:
когда читаешь (у тех же GoF, например), теоретически все понятно.
То к гофам добавить особо нечего.
На практике медиатор не есть необходимым условием, ровно как и все остальные паттерны, как и любые другие задачи - те которые решает медиатор, можно решить иначе.
Для меня задача медиатора состоит в том, и этим он для меня полезен - я за медиатором инкапсулирую несколько сущностей, чтоб с точки зрения упомянутой системы они выглядели как одна.
Изометрия:
С изометрией:
Контроллер не знает что у меня есть вью террана(у которой внутри еще тайлы), вью города(у которой внутри здания), вью жителей, дорожного траффика, неба, партиклов.
Контроллер видит мой медиатор города и всё.
Кроме того. Медиатор например слушает клики по зданиям из вью города. Оборачивает в нечто свое, и в контроллер уже посылает более понятную для контроллера информацию.
Да, это можо сделать и корневой вью, в которой ветками будут все эти вью. Но сам по себе медиатор технически не есть визуальным объектом. Это композиция визуальных объектов. Хотя с точки зрения контроллера он и выглядит как вью. Поэтому вот он выделен как отдельная сущность.
Второй пример который я приводил - медиатор попапов.
В этом случае контроллер вообще не вкурсе сколько в нашей программе попапов и что они умеют.
Контроллер умеет понимать несколько сообщений из медиатора: купить что-то, например, или открыть какое-то другое окно.
Про открытие/закрытие попапа контроллер вообще не догадывается. Он просто видит медиатор, и медиатор для него всегда открыт (ну или можно его закрывать, это уже не суть важно).
Опять же. Визуал у нас в попапах. А медиатор просто предоставляет апи аналогичное вьюхе. Но сам по себе не есть вьюхой. Это композиция из всех входящих в него попапов.
Третий пример банально любой компонент.
У нас есть кнопка.
Рисованная, визуальная, кликабельная.
Мы можем контроллером подписаться на эту кнопку, но лучше обернуть ее во что-то и саму логику нажатий инкапсулировать там. Вот это что-то и будет медиатором. (Но в таком исполнении медиаторы не очень люблю и считаю оверхедом, так как можно эту логику инкапуслировать во вью кнопки).
С таким взглядом на медиаторы мы еще более отделяем логику от представления.
У нас получается совсем простое представление, которое даже правильно отрисоваться не умеет, которое даже модель слушать не умеет. Это просто скин. А вокруг скина медиатор, который подписан на модель, и на который подписан контроллер.
Еще по аналогии с кнопкой. Я приводил пример с казино. Вот наш медиатор умеет работать с разными машинами-скинами. В которых минимально отличается логика поведения визуала (партиклы другие, эффекты другие). Но контроллеру на это пофиг, а медиатор эти шкурки с анимашками легко внутри себя переключает. Контроллер же просто видит что мы сейчас в игровом окне, в котором есть игровая машина, всё.
Psycho Tiger
31.10.2013, 16:19
[Offtopic]
Чувствую скоро забью на все паттерны и пойду функциональщину на петоне клепать.
Я так и сделал. (только Ruby/CoffeScript, who cares?) Чувствую себя счастливее. Расстраиваюсь, если всю мою мысль не получается написать одной элегантной строчкой кода.
В них всесторонне развиваешься
Это ещё что! Например, в сетевых кабелях летают электроны (или что там летает): есть электрон – получаем единичку, нету – получаем нулик. Это не секрет, но есть проблема: когда электрон доходит до какой-нибудь точки – это может быть его конечная точка или даже ретранслятор – он отражается и летит в другом направлении. Это проблема. Поэтому на концы ставят специальные штуки, которые гасят сигнал и этого не происходит. Так о чем это я: знаешь как эти штуки называются? Терминаторы :)
Dukobpa3
31.10.2013, 16:19
Главное что нужно понять:
Медиатор НЕ ВИЗУАЛЬНЫЙ ОБЪЕКТ.
Но с точки зрения контроллера ведет себя как вью.
И вот если вам нужен такой враппер над вашей или вашими вью - это будет медиатор.
Wolsh, если в двух словах, то медиатор это контроллер вида. Его задача передать виду модель, слушать от вида события и передать их куда следует. При этом вид ничего не знает о том как устроено приложение.
Dukobpa3
31.10.2013, 16:26
передать виду модель
Даже это не обязательно. Он может сам слушать модель и паблик методами рулить совсем глупой вьюхой которая даже рисоваться не умеет.
Dukobpa3 - ну а чем же оно будет отличаться от обычного контроллера? Никто не поймет именно почему назвали МЕДИАТОР тогда - что в нем особенного? Весь смысл в том, что походу вы сами не понимаете в чем его суть, по скольку сначала говорите верные вещи, а когда доходит дело до реализации - получается, что медиатор такой же стандартный контроллер как и все. Он слушает события от вью ( все контролы могут слушать от вью) , он запихивает модель во вью ( все контролы так делают, почему нет?) . Рулить паблик методами - так же может любой контроллер - по MVP. А вот слушать модель - это уже интересно. Для чего контролу слушать модель? что он может от этого вынести для себя?
Psycho Tiger
31.10.2013, 16:38
Ну, медиатор, например, не меняет модель напрямую.
Я Dukobpa3'a почему - то понимаю )
Dukobpa3
31.10.2013, 16:43
сначала говорите верные вещи
Верные - это которые с твоей картинкой мира совпадают?:)
Я вроде нигде сам себе не противоречил потому последнего комментария не понял в свой адрес.
Медиатор это не контроллер. Медиатор это по сути своей вью.
Но вместо того чтобы рисоваться на екран самому - он помогает рисоваться своим детям.
На этом его обязанности заканчиваются.
И с точки зрения того же контроллера или "системы" - как я назвал этот уровень абстракции - медиатор это вью. Т.е. он обязан выполнять все фнукции вью для системы:
- слушать модель.
- диспатчить в контроллер.
Медиатор может оставить модель внутри себя, и рулить вьюхой напрямую через паблик методы, не позволяя ей думать вообще. Может отдать модель или часть модели вьюхе, тогда вьюха сама отрисуется, и медиатор возьмет на себя более глобальные визуальные задачи, например смену стейтов вьюхи, если их несколько и в таком духе.
Тем самым медиатор инкапсулирует в себе все внутренности архитектуры нашей вьюхи, или нескольких.
Psycho Tiger
31.10.2013, 16:43
Ладно, придумал минимальный пример:
Есть игра, в которой можно управлять чуваком самому или им может управлять компьютер.
Сам чувак, который умеет бегать влево-вправо (менять свою координату, показывать анимацию) – вью.
Медиатор 1: компьютер.
Медиатор 2: игрок.
С точки зрения вью: она не знает, кто им управляет. Это может быть хоть виртуальный шлем для котейки.
С точки зрения контроллера: он не знает, кто им там управляет. Да ему и по барабану.
Dukobpa3
31.10.2013, 16:44
Рулить паблик методами - так же может любой контроллер
г-нокод детектед:)
В идеале контроллер не должен этого делать. Максимум это спрятать/отобразить вью. Но рисоваться и обновляться она должна сама, иначе никакого профита от мвц не будет.
Добавлено через 4 минуты
Сам чувак, который умеет бегать влево-вправо (менять свою координату, показывать анимацию) – вью.
Медиатор 1: компьютер.
Медиатор 2: игрок.
Я б логику ИИ в медиатор не пихал конечно, но вцелом пример годный.
Медиатор компа эмулирует клики, а дальнейшая схема работает как и с живым игроком - контроллер получил клик, отдал модели, модель поменялась вью отрисовалась.
//******************
Просто я бы сразу сделал либо два режима работы контроллера. Либо два контроллера. Короче добавил бы че-то более массивное и более приспособленное для тяжелых вычислений.
Моя логика ИИ была бы в какой-то связке контроллер-модель. Но не в медиатор-вью.
Добавлено через 14 минут
Т.е. я бы эмулировал не несуществующие клики, а уже готовые решения модели либо контроллера на основании несуществующих кликов.
alexcon314
31.10.2013, 17:05
Wolsh, пора писать пятнашки на медиаторах :)
Dukobpa3
31.10.2013, 17:08
Для пятнашек я бы обошелся одним контроллером и двумя медиаторами:)
- контроллер ВСЕГО
- медиатор интерфейса
- медиатор игрового поля
alexcon314
31.10.2013, 17:10
Гут, профит где? :) Разверни мысль.
Даже это не обязательно. Он может сам слушать модель и паблик методами рулить совсем глупой вьюхой которая даже рисоваться не умеет.
Естественно не обязательно, он также может и не слушать ничего и вид может не иметь модели и т.д. Я же написал "в двух словах" и не обещал рассмотреть все пограничные случаи.
Никто не поймет именно почему назвали МЕДИАТОР тогда - что в нем особенного?
Для этого достаточно посмотреть значения слова mediator. Он выполняет функции посредника между видом и бизнеслогикой приложения. При этом не важно как создаются виды (сегодня это Flex, а завтра передают все на Feathers), они абстрагированы от логики приложения с помощью медиаторов.
Dukobpa3
31.10.2013, 17:18
Гут, профит где? Разверни мысль.
Без скинов нету профита.
Проще в пару классов всё всунуть. Одна модель на всё приложение и какое-то дерево вьюх на пару уровней.
Не уверен что контроллер нужен даже.
А со скинами - при наличии медиатора одни и те же пятнашки могут старлингом рисовать с партиклами в 3д, а могут шейпами и псевдографикой.
Опять же и без медиатора можно, но тогда как минимум с ивентами будет попа в том же старлинге. Из старлинговских пятнашек в контроллер ниче не продиспатчишь нормально, или же придется тупо всё на старлинг перепиливать.
При наличии медиатора - медиатор может реализовывать интерфейсы стандартных флешовых ивентов и для старлинга содержать небольшую оберточку для конвертации.
Медиатор сможет понимать и старлинг кубики с партиклами и шейповые анимации на дефолтном ДЛ.
Эту абстракцию можно и прямо в контроллер вынести, но тогда он станет большим и толстым. С медиатором изящнее.
Есть и другие варианты реализации этой задачи, но раз уж речь о медиаторах ;)
Спасибо всем за объяснения.
Вот как я понял [паттерн] медиатор, когда читал GoF:
"Медиатор это бригадир контроллеров")))
Решающий, например, такие задачи как замена одного контроллера на другой (ну а кто решит такую задачу? не Модель же будет "менять" контроллеры, правда? Она и о текущем то ничего не знает, тем более о Вью, которую контроллер контролирует. Может, Вью будет решать? Вью — решать? Ну а Контроллер, который я мыслю только тонким, тот вообще не в курсе что происходит). То есть вот например поменялось у игры состояние, открыли меню Паузы, или даже окно Инвентаря. И всякие там клики и движенья мышкой по экрану имеют совершенно другой смысл, нежели в процессе боя. Строго говоря, мы активировали другую вьюшку и она через свой контроллер фигачит свои особенные события в свою особенную модель. А "пацаны то не знают!". Представим на секунду, что действия в Инвентаре должны так же влиять и на окно самой игры. Например, выпил герой элексирчика и порозовел. Поменял меч на щит. Надел защищающий от огня амулет и перестал гореть (в некоторых играх инвентарь не только позволяет видеть, что там в игре происходит, но иногда даже не останавливает время в игре (напр. STALKER). Теперь еще одно примечание — все эти же действия (выпить элексир, надеть амулет, взять щит и т.п.) могут инициироваться игроком и безо всякого окна инвентаря нажатиями на особые "быстрые" клавиши. То есть механизм вью-контроллер-модель для таких действий уже существует и БЕЗ контроллера окна инвентаря. Другими словами, уже есть [другой] контроллер, способный передавать в модель эти действия, но он не связан с вьюхой инвентаря. С другой стороны, съеденная нажатием "быстрой клавиши" во время боя аптечка должна сократить кол-во аптечек в инвентаре, а не только поправить здоровье. Так вот Медиатор в моем понимании это тот, кто может устанавливать подобную связь, дергая в контроллере "выпить эликсир" при действиях пользователя в РАЗНЫХ окнах (вьюхах). То есть ловить разные события от разных вьюх и, интерпретируя их как одинаковые, дергать соответствующие контроллеры И инвентаря, И боя, И чего-то там еще (HUDа, к примеру). Медиатор обеспечивает перекрестную подписку разных контроллеров на разные события, а так же управляет наборами таких подписок в зависимости от "состояний" приложения.
Это то, как понял я. Это не соответствует действительности?
Dukobpa3
31.10.2013, 17:26
Это не соответствует действительности?
Моей - нет.
г-нокод детектед Это MVP - когда контроллер запускает методы View. Учите матчасть
Dukobpa3
31.10.2013, 17:39
В моей действительности все контроллеры всегда активны, равно как и все модели.
Т.е. они всегда готовы принять команду от пользователя, все одновременно.
И вот есть допустим контроллер инвентаря. И модель инвентаря.
И есть контроллер куклы игрока, и модель куклы игрока.
Теперь как происходит распитие напитков вызывающих порозовение без учета вьюхи:
- Контроллер инвентаря дергает модель инвентаря.
- Модель инвентаря расходует эликсир. И каким-то чудом эта же информация попадает в модель куклы (мол мы эликсир не просто выкинули, а всё-таки выпили) (как именно эта информация туда попадает - тонкости реализации. Я видел реализации с бабблингом по моделям, видел с обсервером, тут уже ваша смекалка и тонкости задачи включаются)
- обе вьюхи видят изменения в своих мделях. Инвентарь показывает на единичку меньше, а кукла розовеет.
//**********************
Теперь добавим сюда вью.
КАКИМ образом запустится этот процесс?
У нас есть хоткей - это вроде как тоже вью, но абстрактная.
Есть окно инвентаря.
Есть еще куча мест в которых мы можем спровоцировать этот клик и дальнешую цепочку.
//*******************
Т.е. это второй вопрос такой же как и "как данные между моделями синхронизируются".
Реализаций море, и ни одна из них не завязана на медиаторах.
Опять же видел бабблинг по вьюхам. Кликнули в панели, а все контроллеры которым надо - получили ивент.
Видел обсервер более топорный (у самого такой).
Видел когда в контроллер инвентаря тупо инжектятся все вью которые могут запустить процесс изменения инвентаря.
//***********************
Т.е. тут вопроса о медиаторе никакого.
//***********************
Медиатор это допустим открыли мы окно инвентаря.
а в окне инвентаря мы можем покупать хоткеями, а можем покупать кликами.
Это по сути две вьюхи - абстракная для хоткеев и визуальная для кликов.
Но контроллеру пофигу. Эти две вьюхи для него выглядят как одна вьюха окна инвентаря. А медиатор уже обе из них слушает. И выдает контроллеру инвентаря универсальное апи работы с инвентарем.
Добавлено через 4 минуты
Это MVP - когда контроллер запускает методы View. Учите матчасть
"В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)[6]:"
Пруф (http://ru.wikipedia.org/wiki/Model-View-Controller)
Раздел: "наиболее частые ошибки".
Добавлено через 15 минут
"Медиатор это бригадир контроллеров"
Медиатор это вью.
И ничего того что не имеет права делать вью - медиатор не имеет права делать.
Т.е. так же как и вью - он не может ничего сделать с контроллером.
Но это дополнительный уровень абстракции. Если вашими словами то это скорее "бригадир вьюх". Просто позволяет сделать вьюхи тупее, а контроллеры тоньше.
Эти две вьюхи для него выглядят как одна вьюха окна инвентаря. А медиатор уже обе из них слушает. И выдает контроллеру инвентаря универсальное апи работы с инвентарем.
То есть ловить разные события от разных вьюх и, интерпретируя их как одинаковые, дергать соответствующие контроллерыОкей же шь?
Добавлено через 20 минут
(я на Вашей совести пока оставлю всякие баблинги между моделями и т.п., не готов сейчас всерьез это обсуждать — мне больше по душе слоистость MVC-структур в проекте, а не одна большая Куча перемешанных моделей, каждая из которых обязана заботиться о других, выступая для них контроллером. Пусть там, где у меня написано контроллерЫ, будет один очень многоплановый контроллер, знающий сразу все модели или их общий фасад МатьВсехМоделей, но не знающий вьюх, замененных Медиатором).
Добавлено через 24 минуты
Смысл, короче, был в том, что контроллерам не надо знать "чужих" вьюх и "чужих" моделей. Координацией занимается Медиатор, а каждый "модуль" остается независимым и самодостаточным == реюзабельным.
"В результате такого понимания MVC разработчики стали писать ко Да шо вы говорите! Совершенно не важно толстый или нет контроллер - сути не меняет, это паттерн MVP. Плохой он или хороший зависит от конкретной ситуации. Плохого в толстых контролах , как я уже сто раз говорил, нет. - все зависит от задачи. При 1-2 контроллах в приложении можно использовать вообще связку - вызов методов контролом главного вида, а так же и слушанье модели видом - каша да получится? То то, то другое?! Только даже в этом случае назвать это *****-кодом не получится, дабы приложение будет работать пускай и по смешанным стандартам, но вполне себе, и к тому же - легко модифицируемо, даже с такой кашей. Но я конечно против каш, лучше либо одно использовать, либо другое.
А *****код это писать так
var i:DisplayObject = null;
function c() { var n:String = "lalal" }
Почему *****код?
а) в таком коде невозможно разобраться и понять что есть что
б) название переменных и функций должно быть логичным
в) i - как итератор предназначен для счетчика цикла и использовать его в других случаях не по феншую
г) Если метод ничего не возвращает - это тип void
И т.п.
Я знаю одного пхпшника, который кодит уже 20 лет, сотни проектов, тысячи клиентов и т.п. - не важно. Так вот он пишет именно такой код для любых языков которые использует, любой метод у него обозначен 1-2 буквами, переменные и того не более. Вот он пишет реальный *****-код, однако стать ценным сотрудником для многих он смог, программы его работают и про утечки памяти никто не слыхивал. А вы тут обсуждаете какую то фигню, считая адекватный паттерн МВП - *****кодом. ну смешно же
Dukobpa3
31.10.2013, 18:35
А *****код это писать так
С моей колокольни если г-нокод инкапсулирован в пяти строках в одном классе это и не г-нокод вовсе.
Его рефакторить это 10 минут делов.
А плохой код это когда у вас вью начинает считать логику, а контроллер подписывается на модель.
Такое г**нище распутывать запаришься. И я вас разочарую - вот такое вот обычно написано красиво. С первого взгляда в нем даже г-нокод идентифицировать сложно.
Добавлено через 30 секунд
приведенный пример это не г-нокод, это плохой коде-стайл.
Добавлено через 1 минуту
Координацией занимается Медиатор
Ну на каком-то уровне абстракции наверное так и есть.
Я более уточненно и приземленно эту ситуацию рассматривал.
Добавлено через 2 минуты
там, где у меня написано контроллерЫ, будет один очень многоплановый контроллер, знающий сразу все модели или их общий фасад МатьВсехМоделей, но не знающий вьюх, замененных Медиатором
Я примерно с такой же точки зрения смотрю сейчас.
Добавлено через 4 минуты
дабы
дабы == чтобы
ибо == потому что
Я примерно с такой же точки зрения смотрю сейчас.Ну так я Вашу и написал)
Это как бы не самая суть дела, чем там занимаются модели друг с другом, медиатор то в их спальню не заходит. Смысл в том, что "HUD" это Вью HUDa, Контроллер HUDa и Модель HUDa. И медиатор позволяет этому так и оставаться, независимой от всего остального триадой.
Я более уточненно и приземленно эту ситуацию рассматривал.Да, Ваше упрощение помогло мне лучше увидеть, более цельно. Спасибо))
Dukobpa3
31.10.2013, 18:54
Ну я рад что помог:)
А плохой код это когда у вас вью начинает считать логику, а контроллер подписывается на модель.
Так в MVP - вью не считает логику ни в коем случае, а контроллер не подписан на модель. Причем тут это? Разговор шел только про то, что при получении данных... ну вот даже пример. Контрол послал запрос на сервер о получении данных, получил - 5 данных нужны для модели ( по ним будет проход логики, рассчеты и т.п. в модели) а 1 переменная просто текстовая строка, которую надо отобразить в поле, в моделе ей делать НУ просто нечего! И вот тогда контроллер при получении даты дергает метод вью view.showHeader(e.vars) - в чем тут плоховизна кода и запутанность? Более насущный пример : чат в игре. Простой чат рассмотрим, просто текст, который надо обновить, опять же в моделе хранить его нечего, если не планируется с этим текстом ничего делать, а просто отобразить в поле. Опять же view.updateChat(e.vars) - пришедшие с сервера на on ( сообщение ) . Это не просто нормальная практика - она логична, чем записывать ненужную инфу в модель, подписываться видом на обновление этого свойства и делать 3йю связь( cotrl - model - view), вместо 1ой.
Добавлено через 3 минуты
То есть использование MVP на практике - это в некоторых случаях необходимость, данность. Уменьшает связи ( а мы за это болеем!) упрощает понимание. Понятное дело, что большая часть данных с сервера нужна в модели , но как я уже сказал меньшая часть там просто не нужна, но интерпретировать ее надо
Dukobpa3
31.10.2013, 19:02
Сервер - это УЖЕ модель.
Это какая такая строка пришла с сервера которой в модели делать нечего? Из модели пришла, но делать ей там нечего. Ок.
Насчет чата.
В модели архив последних сообщений. Например с буфером в 100 сообщений.
С сервера пришли новые строчки. Старые стерлись новые добавились, во вью прокричали, вью отобразила.
Плоховизна в том что одно действие из двух мест делается. А должно из одного.
Если вью рисуется по модели - пусть рисуется.
Добавлено через 8 минут
Я немного скривил душой.
У меня тоже есть динамические летающие модельки.
Это такая же модель как и все, но она заполняется в момент получения данных с сервера, на лету пристегивается к нужной вьюхе, и нигде не сохраняется.
Только при этом я не нарушаю структуру мвц.
Я просто у вьюхи (например вью попапа) меняю ее модель, а сам процесс как с обычным взаимодействием модель-вью. Вью когда ей модель меняют полностью рендерится ну и прочие плюшки.
Сервер - это УЖЕ модель. Вот неправда. Нельзя однозначно назвать сервер моделью. Я бы скорее его вьюхой назвал, потому, что на своем уровне он ПРИЛОЖЕНИЕ, а приложение в глобальном смысле слова - это вью. Main - во флеше это вью ))) Ну не будем вдаваться . В данном случае можно и моделью обозвать, ничего не меняется.
В модели архив последних сообщений. Например с буфером в 100 сообщений. Я сказал - простой чат, обновление постоянно на str += vars - никаких архивов и перерисовок. Нечего всему тексту в модели делать, тем более кол-во строк может перевалить за Х, а вот БД держать это может - вы путаете холодное с маслом.
Плоховизна в том что одно действие из двух мест делается. Да не одно это действие, тебя перебудеить невозможно, лишь потому, что ты упираешься рогами в свою концепцию , я же смотрю глобальнее, с точки зрения, что ситуации разные бывают и разные бывают приложения и архитектуры.
Зашел в игру : должен получить текст правил игры ( большой текст, или маленький не важно ). Чего делать тексту правил ( статическая фигень) в модели ? Какие к черту рассчеты и логика, зачем им там быть? Я один раз вписал их в вид через контроллер и забыл про них навсегда! Я же знаю, и на будущее знаю, и на прошлое и работая в команде и все что угодно - что модификация ТЕКСТА делается на сервере и во флеше с ней точно ничего не будет происходить НИКОГДА! - да да сохраню в модели ... фигли , чем толще модель с 10000 данных тем лучше, поиск то никто не отменял?! Найду по контексту!
Не гулпите - MVP - необходимость.
cleptoman
31.10.2013, 19:28
что на своем уровне он ПРИЛОЖЕНИЕ, а приложение в глобальном смысле слова - это вью
приложение - это в глобальном смысле слова приложение..возможно на клиентской стороне это и справедливо.
cleptoman - тем не менее войди в дискуссию, ты тоже считаешь, что я не прав по поводу MVP ?
Dukobpa3
31.10.2013, 19:43
Все всегда правы в своей субъектинвой реальности:)
Так как я пишу по МВЦ, то для меня минимальный оверхед в общении с сервером это представить его в виде модели.
Это не еще одна модель.
Это МОЯ модель.
И когда я отправляю-получаю запрос - я просто синхронизирую свою модель с серверной.
Вот и вся загадка.
При чем роль коннектора и протокола в этой схеме настолько мала что на ней даже останавливаться не стоит.
А как там у вас в мвп я не знаю. То что я по картинкам и описаниям увидал - так это один глобальный минус.
Дисконнект сервера и всё упало, потому что ничего нет, нигде, только на сервере.
Dukobpa3 - ну может перестанем переворачивать слова? Я сказал что методика MVP - полезна, в НЕКОТОРЫХ ситуациях, в каких я привел примеры, а вот ДЕЛАТЬ все на MVP - Не стоит, это да, минусы есть. А насчет дисконнект сервера и все упало - вообще фразы не понял, что упало? куда упало? где пропало? Поконкретнее - а то может мы вообще о разных вещах говорим
cleptoman
31.10.2013, 19:53
cleptoman - тем не менее войди в дискуссию, ты тоже считаешь, что я не прав по поводу MVP ?
я на такие провокации не ведусь..я не то чтобы писать..я читать уже устал про MVC....делом лучше займись...100% простой по очередной рулетке )
Dukobpa3
31.10.2013, 19:57
Давайте обсудим модульную архитектуру проекта лучше.
Вот например:
- есть у нас главное приложение.
- есть модули функциональные (всякие там инжектящиеся в логику. Калькуляторы внешние сменные и прочая муть, которую можно вынести из приложения. Парсеры какие-то, подкгружаемые библиотеки.)
- есть модули уровня приложения. Плугины так называемые. Каждый плугин выглядит по-разному. Работает по разному. Да и вообще отличается. Нечто у них есть общего, безусловно, они же все-таки модули одного приложения. Но это самодостаточные взаимозаменяемые или же взаимодополняющие куски.
Итак, господа. Ваши варианты реализации?
Нельзя так ставить вопрос. Господа вам не ответят. Надо придумать хотя бы что это за приложение будет. Например делаем аналог фотошопа или делаем изо-стратегию, не важно что, но от этого идет выбор архитектуры - от того, что будем делать.
Dukobpa3
31.10.2013, 20:07
Нельзя так
Ок, больше не буду. Пойду:)
Akopalipsis
31.10.2013, 20:29
Обьясните пожалуйста, кто инициализирует медиатор и как он получает ссылки на свою вью и модель и контроллер?
Сервер - это УЖЕ модель.
Браво! Одна из здравых мыслей.
Лично я под моделью понимаю организацию данных. Их у меня три типа для актуальной логики, вида и сервиса и все представлены XML объектом. Ноды моделей для логик, видов и сервисов.
Добавлено через 15 минут
У меня понятие "модель"==="датапровайдер", а понятие "логика"==="модель" в смысле MVC
Dukobpa3
31.10.2013, 21:13
кто инициализирует медиатор
Я там выше писал. Медиатор это грубо говоря - вью. Соответственно медиатор логично инитить так как предполагается инит вьюх.
Но не факт.
Вообще я бы не хотел останавливаться на моментах инициализации так как это можно сделать совсем по-разному, и все варианты будут правильными. Мы об этом уже где-то общались.
"модель"==="датапровайдер", а понятие "логика"==="модель"
Как-то так, да. Можно еще подробнее на понятии логики остановиться, но оч неохота. Медиатор же своего рода тоже логика, и контроллер тоже. Но их сферы ответственности можно четко разделить.
Akopalipsis
31.10.2013, 21:17
Я там выше писал. Медиатор это грубо говоря - вью. Соответственно медиатор логично инитить так как предполагается инит вьюх.
Ну так если говорить словами не книжными, то медиатор - это контроллер ( маленький ) для своей вью, который имеет доступ к главному контроллеру. И если назвать его не медиатор, а контроллер, то получается, что он инициализируется во вью.
Добавлено через 1 минуту
А то что он может быть контроллером для двух или более вьюх С ОДИНАКОВОЙ ЛОГИКОЙ, это само собой разумеется.
Чего особо останавливаться? Клиентская логика (если она есть) посылает или не посылает команды сервису, который в свою очередь рассылает данные для видов, для их обновления.
Добавлено через 2 минуты
Akopalipsis, это всё делается для модульности, чтобы выдернув или вставив очередной модуль ты не нарушил работу приложения.
Dukobpa3
31.10.2013, 21:29
инициализируется во....
Вот давайте не трогать инициализацию.
А то с мвц тема прлавно перейдет на DI & IOC и там уже будет холивар похлеще.
Немного надоело. Инит в каждом проекте может быть разный.
В каждом фреймворке разный.
Да хоть в мейне все связи утанови а потом используй.
А можешь в главном контроллере всё сделать.
А можешь сделать главный контроллер, модель, вью, медиатор.
И от них уже деревья и ветки чилдов распускать.
Как твоя душа желает. Однозначного ответа тут нету и не может быть.
Инит может меняться в процессе работы.
Добавлено через 1 минуту
Дуко, прощается, но не уходит:)
Dukobpa3
31.10.2013, 21:36
Я уходил, хряпнул коньячка, тепреь вернулся полон сил. Буду вас еще тут поддерживать всячески, но уже менее активно:)
Архитектурная тематика мне оч близка, и в моих интересах сеять разумное доброе вечное, а вдруг потом с каким-то падаваном с форума работать придется, а ему объяснили не правильно. Вот сам контролирую процесс так сказать.
Мне уходить не надо, коньячок всегда у стола:)
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.