Форум » Вопросы о разработке игр » Паттерны проектирования » Ответить
Паттерны проектирования
Mystic: Вопрос, возможно, глупый. Но ответьте, пожалуйста: какие паттерны проектирования чеща всего применяются и в каких ситуациях именно в играх? И какие паттерны вообще можно (или даже лучше) не применять. Не надо отвечать по всем паттернам, просто приведите несколько примеров. ЗЫ: Почему бы вам не попробовать перевести книги по проектированию движка игры? Алгоритмы, графика и тд можно изучить и самому, а вот понять архитектуру приложения достаточно сложно. В книге «Программирование ролевых игр с DirectX (2-е издание)» есть что-то похожее, но далекое от идеала (как мне кажется). Если я что-то неправильно сказал, поправьте меня)
Ответов - 6
netlib: Mystic пишет: какие паттерны проектирования чеща всего применяются Слишком общий вопрос. В двух словах на него не ответишь. Вообще какие паттерны применять очень сильно зависит от ситуации и от типа приложения (однопользовательское или сетевое, пошаговое или работает в реальном времени и т.д.). Mystic пишет: Почему бы вам не попробовать перевести книги по проектированию движка игры? Порекомендуйте какие-нибудь книги.
Mystic: netlib пишет: Порекомендуйте какие-нибудь книги К сожалению, не знаю о таких книгах. Если бы знал, смог бы сам перевести (как мне кажется, там вряд ли труднее мсдн). netlib пишет: Слишком общий вопрос. В двух словах на него не ответишь. Ладно, попробую в будущем как-нить конкретизировать вопрос.
netlib: Попробую помочь вам конкретизировать вопрос. Скажу сразу, что под паттернами проектирования я понимаю способы решения типовых задач, возникающих в объектно-ориентированном программировании. Если вы подразумеваете что-то другое, то напишите мнечто именно. Ну и далее список паттернов: Абстрактная фабрика Abstract Factory Строитель Builder Фабричный метод Factory Method Прототип Prototype Одиночка Singleton Адаптер Adapter Мост Bridge Композиция Composite Оформитель Decorator Фасад Facade Маховик Flyweight Заместитель Proxy Цепочка ответов Chain of Response Команда Command Интерпретатор Interpreter Итератор Iterator Посредник Mediator Напоминание Memento Наблюдатель Observer Состояние State Стратегия Strategy Шаблон метода Template Method Посетитель Visitor Естественно, даже при беглом взгляде на этот список ясно, что такие шабоны (паттерны) как итератор, состояние, посредник применяются повсеместно. В то же время есть и шаблоны, которые применяются гораздо реже. Давайте, чтобы было проще вы спросите какие шаблоны вас интересуют. Кстати, я вполне допускаю, что данный список паттернов не полный, добавьте туда свои .
Mystic: Конечно, этот список не полный, но это все (вроде бы) наиболее общие паттерны. Организацию шаблонов я знаю и знаю как их применить, но вот не знаю только, где их надо применять. Слишком уж их много и какой выбрать для некоторой ситуации - непонятно. В качестве примера (просто для конкретики) можно рассмотеть что-нить вроде надстройки над винапи. Допустим, такие объекты, как иконки, битмапы и курсоры. Можно для каждого из них создать класс. Можно сделать некий абстрактный класс GDIObject, и от него породить эти три класса (этот вариант мне кажется лучше). А вот что лучше сделать с точки зрения паттернов (прежде всего для гибкости программы и ее расширяемости)?
netlib: Mystic пишет: прежде всего для гибкости программы и ее расширяемости В игре вам в первую очередь нужна производительность. Поэтому в общем случае если и используются классические паттерны, то в сильно упрощенном и урезанном виде. Вы пишете Mystic пишет: Допустим, такие объекты, как иконки, битмапы и курсоры. Можно для каждого из них создать класс. Можно сделать некий абстрактный класс GDIObject, и от него породить эти три класса Это все можно, но чтобы выбрать паттерн надо знать зачем вы это делаете и для какого приложения. Если важна производительность - один случай, если это распределенное приложение - другой. Тут даже от количества разработчиков и способа взаимодействия между ними многое зависит.
EViruS: Есть 2-3 изданные в России книги по паттернам проектирования. http://bolero.ru
полная версия страницы