Как написать сплошную Pure Aggregation (композицию) игровых объектов на Java? - PullRequest
Новая
       44

Как написать сплошную Pure Aggregation (композицию) игровых объектов на Java?

9 голосов
/ 05 апреля 2011

Итак, я только начинаю писать игру на Java и пишу свои игровые объекты.Теперь я прочитал здесь, в Evolve Your Hierarchy , что вы должны строить свои игры как композиции, а не как иерархию большого класса.Как показывает это изображение из предыдущей ссылки:

enter image description here

Однако, когда я приступаю к реализации, у меня возникает один маленький вопрос о том, где применять интерфейсы.

Допустим, у вас есть класс Player и интерфейсы Moveable и Renderable.Вы реализуете это, используя переменные открытого интерфейса: 

class Player {
    public Moveable moveable;
    public Renderable renderable;
}

class GenericMoveable implements Moveable {
    // Function implementations
}

class PlayerRenderable implements Renderable {
    // Function implementations
}

Или вы пытаетесь сделать это, применяя интерфейсы непосредственно к объекту: 

class Player implements Moveable, Renderable {
    private GenericMoveable genericMoveable;

    // Non-direct Implementation of Moveable
    void someMoveFunc(double x, double y) {
        genericMoveable.someMoveFunc(x, y);
    }

    // Direct implementation of Renderable
    void someRenderableFunction() {
        // Player class specific code
    }
}

class GenericMoveable implements Moveable {
    // Function implementations
}

Теперь в настоящее время я чувствую, чтоВторой способ лучше.Основная причина этого заключается в том, что я могу создать следующие списки: 

List<Renderable> renderObjects; // use this to draw all of the objects to the screen
List<Moveable> moveObjects; // use this to move all objects at once

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

Хотя, пока мы находимся здесь, на что еще мне нужно обращать внимание при реализации Compositional Game Objects в Java?Что я должен делать по-другому?Спасибо за любые ответы заранее, я ценю любую помощь.

Ответы [ 2 ]

4 голосов
/ 05 апреля 2011

Я создал несколько игр, использующих java, а также видел исходники нескольких очень хороших игр, и, кажется, самый распространенный способ сделать это - второй метод.Из того, что я могу сказать, лучшая причина для использования второго метода заключается в том, что становится легче отслеживать ваши объекты с помощью списков и позволяет рисовать с использованием меньшего количества линий.Кажется, вы на правильном пути, и статья Evolve Your Hierarchy отлично подходит для начинающих разработчиков игр.

2 голосов
/ 05 апреля 2011

Это интересная ссылка.Я понял, что то, что вы имеете в виду для своего Player класса, - это то, что эта статья называет контейнером компонентов.Для этого применение интерфейсов к классу звучит для меня как путь.Это единственный маршрут, который приведет вас к чистой структуре агрегации (где в вашей системе больше нет Player класса per se .

Кстати, структура, которую вы 'повторное предложение в основном является приложением шаблона проектирования делегирования . A Player полагает делегатов к объекту Movement во всех операциях перемещения, и ему все равно, какой именно тип Movement объекта он долженработа с.

...