Gamedev LectureСтатьи

Лекция #14. Паттерны revisited. Введение. [Лектор - aruslan] (4 стр)

Автор:

[02:35] <aruslan> -- GoF
[02:36] <aruslan> В GoF очень мало про реальные паттерны, там очень много про то, как конкретно реализовать и защитить то или это.
[02:36] <aruslan> Чисто C++, даже я б сказал - чисто Java.
[02:38] <aruslan> (сцылки - еще читать Фаулера минимум рефакторинг, читать
[02:38] <aruslan> http://alistair.cockburn.us/crystal/articles/cpanfocisd/character… onlinear.html
[02:38] <aruslan> и читать де Марко - всего - это для общего развития)
[02:39] <aruslan> Специфика языка (в особенности - Java) наложила резкий отпечаток на GoF.
[02:39] <aruslan> То есть во многом - это старое ОО, таким, каким оно было в средней своей фазе.
[02:39] <aruslan> Грубо говоря, это ОО, когда virtual было в public, когда народ не умел MPL и DSEL в C++, и очень любил наследование.
[02:40] <aruslan> И с функторами была напряжёнка.
[02:41] <aruslan> Что не надо называть паттернами вообще:
[02:43] <aruslan> - Синглтон http://www.livejournal.com/users/_winnie/18677.html
[02:43] <aruslan> (сцылки - вот на русском немножко: http://aruslan.livejournal.com/19479.html )
[02:44] <aruslan> - Command - GoF ясно пишет "чтобы поддерживать связь", но толку как с козла молока, в C++ - лучше функторы.
[02:46] <aruslan> - Visitor - мощная штука, но жёстко завязана на конкретные языки обратной связью.
[02:47] <aruslan> - Observer - в GoF очень низкоуровнево, смотрите в POSA или вообще забейте.  slot-signal или аналоги или функторы.
[02:48] <aruslan> - Memento - GoF очень хотел, но так ничего и не сказал.
[02:48] <aruslan> - Strategy - идея ясна, но паттерн в чистом виде из себя не представляет.
[02:50] <aruslan> - Facade - это подход, а не паттерн
[02:51] <aruslan> Технически мы сейчас говорим о паттернах проектирования и архитектурных паттернах.
[02:52] <aruslan> В GoF - смесь.  Элементы смеси - идиомы и подходы.
[02:52] <aruslan> Синглтон - скорее идиома (хотя, честно, говоря, вообще неизвестно что).
[02:53] <aruslan> Visitor - идиома.  Попробуйте объяснить её смысл человеку с других языков.
[02:53] <aruslan> Strategy - если это паттерн, то наследование - автоматически паттерн тоже.
[ выкрик из зала - aruslan не любит синглтоны ]
[02:53] <aruslan> Не люблю, да.
[02:53] <aruslan> Визиторов, кстати, я тоже не люблю.
[02:53] <aruslan> Кстати, всё что я здесь говорю - это такое моё имхо, если кто не заметил :)
[02:54] <aruslan> Смотрите выше.  Поэтому GoF читать можно и нужно, но это не те "паттерны", о которых реально говорят.
[02:54] <aruslan> Смотрите выше - я имел ввиду - уровнем выше.
[02:54] <aruslan> GoFовские паттерны нужно рассматривать блоками, тогда значительно яснее, почему так а не эдак.
[02:55] <aruslan> Вот эти блоки - типично паттерны POSA и иже с ними.
[02:55] <aruslan> Что НУЖНО знать из GoFа.
[02:56] <aruslan> Хм.
[02:56] <aruslan> %)
[02:56] <aruslan> Структурные и порождающие, я думаю.
[02:57] <aruslan> То есть их нужно реально хорошо знать, потому что реализовывать их придёццо не раз.
[02:57] <aruslan> Причём знать их в идеале нужно не только в GoF-вариантах.
[02:58] <aruslan> Шото я заибался.
[02:58] <aruslan> -- дзен
[02:59] <aruslan> Как уволиться и замучать тимлида.
[02:59] <aruslan> По поводу кнопки и GUI.
[02:59] <aruslan> Подготовка очевидна - внимательно смотрите на предлагаемую архитектуру кнопки и GUI, дальше делаете следующее.
[03:01] <aruslan> Для каждого из нижеперечисленных пунктов договариваетесь с дизайнером, что это самое нужное в этом GUI, и мучаете тим лида, что плохо вписывается.
[03:01] <aruslan> 1. Порядок слоёв и рендеринг.
[03:01] <aruslan> Если тим лид инертный, вы его не заденете фразой "на всех ста кнопках нужно сначала отрендерить фон, потом текст и т.п." вместо "сначала рендерим фон всех кнопок, потом весь текст и т.п."
[03:02] <aruslan> Но повод задуматься по поводу порядка отрисовки (точнее, его резкой смены) у него появится.
[03:02] <aruslan> На следующий день:
[03:02] <aruslan> 2. Локальные эффекты.
[03:02] <aruslan> Наведение мышки - подсветка, наведение мышки - увеличение и т.п.
[03:03] <aruslan> Обычно во вменяемом ГУИ это всё встроено.  В худшем для вас случае - встроено через скрипты или простой код.
[03:03] <aruslan> В лучшем - не встроено или нельзя навеситься и на наведение и на нажатие и т.п.
[03:04] <aruslan> Спрашиваете, как здесь лучше сделать.  Стратегией? Интерпретатором? Декоратором?
[03:04] <aruslan> 3. Нелокальные эффекты.
[03:04] <aruslan> Нажали тут - задизаблилось там. - это просто MVC или PAC, обычно тим лид этот ход уже предусмотрел.
[03:05] <aruslan> А вот разноцветные кнопулечки - очень тяжело сделать локальными скриптами, типично скрипт должен знать о структуре диалога.
[03:05] <aruslan> То есть если диалог - композит, потребуется как-то искать другую кнопку.
[03:06] <aruslan> Обычно готовое решение тим лида - либо пространство имен и метод "FindXXX", либо явная data driven композиция с приаттачиванием скрипта сразу на несколько кнопок.
[03:07] <aruslan> И то и другое не работает, если
[03:07] <aruslan> 4. Резкое усложнение иерархии кнопок (либо внутри кнопки)
[03:08] <aruslan> Если тупо всё сделано композитом, то многослойная кнопка (кучи картинок, несколько рамок, скрыли один вид, включили другой) резко сорвёт башню тупому поиску.
[03:08] <aruslan> Чтобы кнопка стала цветастой, придёццо искать не один, а сразу несколько слоёв.
[03:08] <aruslan> Типовые решения - pattern matching, в простейшем случае - FindXXX("*/button*/text*")
[03:09] <aruslan> 5. В этот момент вы опять спрашиваете про порядок слоёв и рендеринга.
[03:09] <aruslan> 6. Затем Главный Дизайнер говорит, что в проекте Солидатор классное ГУИ, и там всё выезжает где попало.
[03:10] <aruslan> Нужно присваивать из скрипта разнообразные атрибуты, и научать всё ездить - это если по-тупому.
[03:10] <aruslan> Типично если жёстко прессовать - именно это решение примет тим лид.
[03:10] <aruslan> ГУИ начнёт пухнуть ради единообразного подхода.
[03:11] <aruslan> Фактически у любого элемента контрольного элемента (текст, битмап и т.п.) окажется хорошее количество параметров, которые можно заанимировать.
[03:11] <aruslan> Анимировать придёццо из скрипта.
[03:12] <aruslan> Понятно, что найти что либо плюс отрисовать всё это в правильном порядке - либо НЕединообразно либо специальные атрибуты типа "Приоритет" и т.п.
[03:12] <aruslan> 7. В этот момент вы истерично кричите "я не буду опять переписывать этот код где кнопка расцвечивается!"
[03:13] <aruslan> Тим лид предлагает более продвинутый вариант Pattern matchingга - не иерархия но тэ
[03:13] <aruslan> тэги, но получаются те же яйца вид справа.
[03:13] <aruslan> Вы объясняете тим лиду, что архитектура - это застывшая музыка, поэтому не должно всё переписываться полностью за неделю.
[03:14] <aruslan> В это время начинаются проблемы с фокусом клавиатуры и перемещением по контрольным элементам через клавиатуру.
[03:14] <aruslan> Edit боксы перестают работать.
[03:14] <aruslan> 8. Chain of Responsibility.
[03:15] <aruslan> Заодно катастрофической становится разница между "всплытием сообщения" по вертикали композиции (агрегации) и по визуальной вложенности.
[03:16] <aruslan> То есть сообщения дохнут и попадают не туда.
[03:16] <aruslan> Есть уже четыре способа перечисления контролов - порядок отрисовки, порядок всплытия сообщений, для поиска контрола и по агрегации.
[03:17] <aruslan> Главный Дизайнер решает, что мгновенное появление всплывающих окошек - это ацтой, они должны неторопливо собираться из специально нарисованных элементов.
[03:17] <aruslan> 9. Интепретатор.
[03:18] <aruslan> Сборка контролов становится тяжелым занятием.
[03:18] <aruslan> Тим лид принимает решение ввести макроязык.
[03:19] <aruslan> Типа template button {...}  а на его основе делаются другие баттоны.
[03:19] <aruslan> То есть прототипы + стратегии.
[03:19] <aruslan> Плюс, конечно же, динамическое добавление дочерних элементов.
[03:19] <aruslan> Композиты резко усложняются на ровном месте.
[03:19] <aruslan> В скрипты вводится visitor с overloading через pattern matching.
[03:20] <aruslan> То есть никаких if в скриптах нет, нет и поисков.
[03:20] <aruslan> Просто если текущий элемент - это (pattern matching) вызывается (скрипт)ю
[03:20] <aruslan> 10. Рендер начинает тормозить.
[03:21] <aruslan> Выясняется, что если переключиться в китайский локаль, всё тормозит.
[03:21] <aruslan> Без китайского, впрочем, тормозит тоже.
[03:21] <aruslan> Потому что 5000 DIPов на кадр, а диалог - прозрачный поверх игры.
[03:22] <aruslan> С китайским - тормозит еще и рендер фонтов.
[03:22] <aruslan> Вы предлагаете тим лиду закэшировать константные строчки, и таки рендерить в другом порядке.
[03:22] <aruslan> Обе операции можно сделать на верхнем и на нижнем уровне.
[03:22] <aruslan> Итого четыре варианта.
[03:23] <aruslan> 11. Какой бы вариант не выбрал тим лид, можно легко построить "самый худший случай" и именно его разрекламировать Главному Дизайнеру.
[03:24] <aruslan> На данный момент половина ресурсов команды уходит на непрерывный рефакторинг ГУИ, и QA отказываются брать последнюю версию.
[03:24] <aruslan> Вы предлагаете делать всё по науке и начать с unit testов.
[03:25] <aruslan> 12. Еще вы предлагаете генерировать из описания диалога в offline оптимальную последовательность рендеринга в C++.

Страницы: 1 2 3 4 5 Следующая »

19 февраля 2006

Комментарии [5]