Смешивание с чертой Akka Actor конфликтует с базовым классом

Я использую фреймворк Akka вместе с jMonkeyEngine (jME3) для своей маленькой игры scala/java. Приспособив некоторую магию диспетчера Akka, мне удалось запустить выделенный актор в том же потоке, что и основной цикл jME3. нить. Чтобы актор имел доступ к защищенным переменным класса SimpleApplication, который нужно расширить для создания игры с jME3, я подумал, что было бы неплохо создать класс, который наследовал бы класс SimpleApplication и смешивал его с < em>черта Актер. Что-то вроде этого:

JmeActor extends SimpleApplication with Actor

Проблема в том, что и SimpleApplication, и Actor имеют переменную context, которая конфликтует друг с другом. На данный момент я переименовал переменную context SimpleApplication в jmeContext и перекомпилировал jME3. Результат работает довольно хорошо, но сам дизайн кажется мне сломанным, так как любой дальнейший выпуск jME3 (или даже Akka) потребует, чтобы я снова провел этот рефакторинг вручную. Возможно даже, хотя и маловероятно, что SimpleApplication будет дополнительно изменен командой разработчиков, что значительно усложнит этот метод предотвращения конфликтов.

Может ли кто-нибудь увидеть простое решение этого?


person gsimard    schedule 11.05.2013    source источник
comment
Почему композиция не сработала?   -  person Viktor Klang    schedule 11.05.2013
comment
Вы имеете в виду создание актера как поля JmeActor вместо смешивания с Актером? Как бы вы настроили функцию получения, чтобы этот актер имел доступ к закрытым полям JmeActor? Это, вероятно, тривиально для вас, но сейчас мне это непонятно.   -  person gsimard    schedule 11.05.2013
comment
Нет, я имел в виду, что JMEActor расширяет Актера, но имеет поле с SimpleApplication. Затем актор принимает сообщения и вызывает методы SimpleApplication.   -  person Viktor Klang    schedule 11.05.2013


Ответы (1)


Моя интуиция подсказывает, что такое тесное переплетение экземпляра Актера с таким богатым классом, как «основной» класс игрового движка, может быть не лучшим выбором дизайна. Я бы рекомендовал создать подкласс SimpleApplication таким образом, чтобы вся необходимая вам функциональность была представлена ​​публичными методами, а затем просто сохранить ссылку на это в вашем акторе; Я предполагаю, что вы хотите иметь возможность влиять на игровой движок, отправляя сообщения актеру, который, таким образом, включен.

person Roland Kuhn    schedule 11.05.2013
comment
Действительно, сам смысл смешивания с Актером заключался в том, чтобы избежать раскрытия защищенных полей с помощью общедоступных методов не только потому, что это такая рутинная работа, но и потому, что инкапсуляция нарушится, если не принять больших мер предосторожности. - person gsimard; 11.05.2013
comment
Инкапсуляция совершенна внутри актора, независимо от того, что говорят модификаторы доступа, поскольку никакой другой код не может вызывать методы или получать доступ к полям актора, кроме как посредством отправки сообщений. С другой стороны, наследование не оставляет вам выбора. жизненный цикл актора/приложения, и необходимо проявлять большую осторожность, чтобы SimpleApplication не подвергался воздействию других потоков, что могло бы нарушить модель актора. Я думаю, что мой ответ сводится к тому, что «jME плохо спроектирован, потому что требует наследования». - person Roland Kuhn; 11.05.2013