Java: доступ к ресурсам и закон Деметры

вы можете использовать инъекцию зависимостей и исключить класс ресурсов. Тогда вы можете вызывать функции на своих полях и не нарушать закон Деметры.

вот пример использования инъекции конструктора:

public class MainMenu implements Scene {

   Background background;
   Hero hero;  
   Enemy enemy; 
   MenuButtons buttons

    public mainMenu(Background background, Hero hero,  Enemy enemy, MenuButtons buttons){

       this.background = background;
       this.hero = hero;
       this.enemy = enemy;
       this.buttons = buttons;   
    }

    @Override
    public void render(){

        this.background.draw();
        this.hero.draw();
        this.enemy.draw();
        this.mainMenuButtons.draw();           

    }

    @Override
    public void updateLogic(){

        this.hero.move();
        this.enemy.move();
        this.mainMenubuttons.animate();
    }

}

с инъекцией зависимостей вы передаете экземпляры в конструкторы и функции вместо "создания" их внутри вашего класса. Однако вам нужно где-то управлять своими экземплярами, и есть много библиотек, которые это сделают для тебя. Кинжал является популярным для Android:http://square.github.io/dagger/

идея передачи списка не является плохим первым шагом, но этого недостаточно. У разработчиков игр есть (несколько спорная) концепция структуры, называемой "графом сцены", которая помогает им отслеживать свои ресурсы (среди прочего). https://en.wikipedia.org/?title=Scene_graph

Это довольно сложная концепция, но рано или поздно вам придется узнать об этом. Есть много хороших советов gamedev.stackexchange.com поэтому я предлагаю вам посмотри туда.

вот хороший видеоурок YouTube по этому вопросу. https://www.youtube.com/watch?v=ktz9AlMSEoA

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

public class Drawer {
   public void drawObjects(Drawable... objects) {
      for(Drawable drawable : objects) {
         drawable.draw();
      }
   }
}

это затем используется Scene рисовать эти объекты.

public class mainMenu implements Scene {
   Resources resources;
   Drawer drawer;

   ...

   public void render() {
      drawer.drawObjects(resources.background, 
                         resources.hero, 
                         resources.enemy, 
                         resources.mainMenuButtons);
   }

   ...
}

аналогичная стратегия, с помощью Updater, может применяться для других методов. Если updateLogic() метод делает так просто вызовов, как это выглядит, вы можете определенно сделать то же самое, сделав все эти объекты наследовать от Updateable интерфейс.

public interface Updateable {
   void update();
}

Heroи Enemy ' s update() методы могли бы просто назвать их move() методы, в то время как MenuButtons ' s update() может делегировать animate(), etc.

очевидно, если вам нравится, вы можете использовать какую-то коллекцию вместо varargs для параметра Drawer ' s drawObjects(). Я просто как хорошая беглость стало возможным благодаря С varargs, так как вам не придется создавать коллекции.

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

Мне нравится концепция ResourceManager.
но ResourceManager должен быть responsilbe для загрузки ресурсов, кэширования и освобождения их.
рендеринг-это определенно метод объекта рендеринга.

Таким образом, метод Scence - render может делегировать ему рендеринг после
создания визуализации и кормить его рисунки в качестве рендера не
ресурсы render но объекты передать.

Скажи:

class MainMenu implements Scene {
    Renderer sceneRenderer = new Renderer();
    AnimatedRenderer animatedRenderer = new AnimatedRenderer();
    ResourceManager resourceManager = ResourceManager.getInstance();
    List<Resource> resources;
    List<Drawable> renderedObjects;
    GameObjectController gameObjectController;


    void initializeScene() {
          resources = resourceManager.getResources();
          renderedObjects = resourcesAsRenderables();
          sceneRenderer.setDrawables(renderedObjects);
    }

    List<Drawable> resourcesAsRenderables() {
      // if resources are not directly renderable, do decoration etc
      // and return a List of Drawable
    }

    @Override
    public void render(){
         sceneRenderer.render();
    }
    @Override
    public void updateLogic(){
       moveGameObjects();
       doAnimations();

    }
    protected void moveGameObjects() {
        gameObjectController.moveAllObjects(this, resources);
    }
    protected void doAnimations() {
        animatedRenderer.render(resources);
    }


    class ResourceManager {
       private static ResourceManager instance = null;
       List<Resource> resources;
       public ResourceManager getInstance() {
          if(instance == null) {
             instance = new ResourceManager();
             instance.loadResources();
          }
          return instance;
       }
       private void loadResources() { 
           resources = new LinkedList<Resource>();
           resources.add(new Hero());
           ....
       }
       public List<Resource> getResources() {
          return resources;
       }
    }

этот четко разделяет логику и ответственность за задачи, выполняемые в течение жизненного цикла сцены. Менеджер ресурсов, который отвечает за извлечение ресурсов и поскольку они могут занять много времени загрузки, делает такие вещи, как кэширование или освобождение в ситуациях с низкой памятью, скрывая детали от клиента. Преобразователь, который отвечает за отображение объектов и контроллер, который отвечает за перемещение объектов. Сам контроллер может реализовать обработчики для событий клавиатуры, но это не то, что должно быть прозрачным для сцены. Визуализатор может менять фон, масштабировать или устанавливать эффекты освещения, но сцена вызывает только свой метод рендеринга. Анимированный визуализатор отвечает за запуск , рендеринг и остановку анимации.

изменить это:

 public void render(){

        resources.background.draw();
        resources.hero.draw();
        resources.enemy.draw();
        mainMenuButtons.draw();           

    }
 @Override
    public void updateLogic(){

        resources.hero.move();
        resources.enemy.move();
        resources.mainMenubuttons.animate();
    }

С этого:

public void render(){
            resources.render();
    } 

@Override
    public void updateLogic(){
        resources.update();
} 

ResourceManager не обязательно знать, что находится внутри ресурсов. Это может быть один враг или десять, он не заботится о ResourceManager.

и так в "ресурсе" вы можете сделать:

  public void update(){
        hero.update();// Cause hero may, or may not move, he makes the choice
        enemy.update();//...
        mainMenubuttons.update();//.
    }
  public void render(){
  ...
  }

больше, чем это! вы можете изменить реализацию "ресурс" с интерфейсом, и вы будете программировать для интерфейсов, а не для реализаций, что круто! Таким образом, вы можете иметь ресурсы для в игре и еще один для меню, которые будут использоваться таким же образом: только изменение, во время выполнения, конкретные ресурсы вы будете в меню или в игре!

в любом случае, не всегда необходимо заполнять Деметры.

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

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