Сегодня выкладываю свою презентацию с КРИ 2008. Она освещает вопросы проектирования видео игр, разумеется, не с гейм-дизайнерской, а с технической точки зрения. В презентации изложены ответы на такие вопросы:
- К каким проблемам приводят слишком большие иерархии классов?
- Чем можно заменить такие иерархии?
- Что брать в качестве основы декомпозиции на подсистемы - функции или объекты?
- Как проектировать AI-водителя для гоночной игры? (Описание примера.)
- Чем "грешит" паттерн "Цепочка обязанностей"?
> Построениене противоречивой иерархии объектным способом невозможно
ОтветитьУдалитьВы вроде разбираетесь в ООП и пишете статьи о проектировании ПО, и по идее должны бы знать, что
использование ООП не ограничивается использованием паттерна "шаблонный метод" где описываются проблемы этого самого простого и черезчур популярного паттерна в ООП и о которых говорится в первой 20-тке из 50 слайдов.
Возможно Вам стоит перечитать азбуку ООП,
http://www.ozon.ru/context/detail/id/2457392/
прежде чем делать громкие заявления.
1) Коллега, в цитате, приведённой Вами, упущена частица 'не'.
ОтветитьУдалить2) Не вижу, где бы я упоминал в презентации шаблонный метод.
1) Почти правы - я пропустил пробел.
ОтветитьУдалить2) да, не упоминали - говоря другими словами, у вас самая обычная проблема злоупотребления наследованием.
В любом случае суть не в этом. Главная мысль в том, что наследование далеко не единственное что есть в ООП. И Ваше, надо сказать, довольно громкое заявление об ограничения ООП в этих слайдах не совсем верно. Эти проблемы уже давно успешно решаются и даже наиболее частые решения обобщены в паттерны проектирования.
Я с Вами согласен - некоторые паттерны изобретены, чтобы устранить проблемы, порождённые классическим ООП. Но лучше проектировать с самого начала правильно и не порождать этих проблем.
ОтветитьУдалить