Как разработать класс, который можно использовать в других проектах - PullRequest
Новая
       24

Как разработать класс, который можно использовать в других проектах

1 голос
/ 27 марта 2019

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

Представьте себе, например, что у нас есть 2 игры: одна - игра в покер, другая - игра, похожая на грандиозную кражу.В игре в покер класс должен иметь id, playersited() : player, state : full, empty, reserved.Я могу думать об этих свойствах прямо сейчас.Но во второй игре кресло не обязательно нуждается в функции id или playersited().Итак, как я могу создать этот класс, который можно использовать в других играх?

1 Ответ

2 голосов
/ 27 марта 2019

Вы ищете общий игровой объект, который вы могли бы повторно использовать в разных играх, но который мог бы иметь разные свойства и разные функции в зависимости от игры.

Простой ответ UML

Если вы смотрите на него только с точки зрения UML, эта проблема проектирования проста: нарисуйте класс GameObject, добавьте в него свойства и операции, которыеты хочешь быть обычнымЗатем в модели ваших разных игр просто создайте специализацию, используя наследование: PokerObject и GrandCloneObject, в которую вы добавите специфические свойства и операции для игры.

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

Ограничения такого общего дизайна

Кроме того, вы хотите твердый дизайн.LSP затем уменьшит возможность повторного использования, заставив вас повторно использовать взаимодействие между объектами, полагаясь только на общую часть.

Если только 10% дизайна действительно пригодны для повторного использования в конце, а 90% зависит от игры, вы не получите никакого преимущества и просто усложните код, искусственно разделив классы.Здесь я бы объединил комментарий @ kigiri: " ПРОСТО НЕ "

Лучший подход

Но если вы ищете, то это действительно многоразовое использование на более высоком уровне.масштаб, есть решение, если вы посмотрите не на Chair, «Оружие», «Предмет», а на более высокий уровень абстракции.

И здесь я могу только порекомендовать вам прочитать книгу Майка Макшаффри Game Coding Complete , в которой вы познакомитесь с очень мощным архитектурным паттерном, называемым Entity Component System .

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

  • Сущностями : это основные объектыиспользуется в игре, независимо от того, какая игра
  • Компоненты : они принадлежат сущностям и представляют любые свойства, которые может иметь сущность (например, LivePoints, Force, ...),или поведение, которое должен иметь объект (например, renderFixedObject, soundWhenClicked и т. д.).

Эта конструкция позволяет создавать объекты многократного использования, позволяющие добавлять специфичные для игры компоненты поверх многократно используемых объектов и компонентов.

...