2015-07-18 3 views
0

У меня есть класс Player, который содержит несколько частных полей других классов (я считаю, что это называется композиция).Методы метода заполнения в композиции

public class Player 
{ 
    private String name; 
    private Statistics statistics; 
    private Experience experience; 
    private Effort effort; 
} 

Я буду размещать только один из них называется Статистика

public final class Statistics 
{ 
    Pool pool; 
    Edge edge; 

    class Pool 
    { 
     private Map<Stats, LimitedInt> map = new HashMap<>(); 
     private int freePoints = 0; 

     void setAvailable(Stats stat, int value){} 
     int getAvailable(Stats stat){ return 0; } 
     void setMax(Stats stat, int value){} 
     int getMax(Stats stat, int value){ return 0; } 
     void setFreePoints(int value){} 
     int getFreePoints(){ return 0; } 
     void spendFreePoints(Stats stat, int amount){} 
    } 

    class Edge 
    { 
     private Map<Stats, Integer> map = new HashMap<>(); 
     private int freePoints = 0; 

     void setMax(Stats stat, int value){} 
     int getMax(Stats stat, int value){ return 0; } 
     void setFreePoints(int value){} 
     int getFreePoints(){ return 0; } 
     void spendFreePoints(Stats stat, int amount){} 
    } 
} 

Он не реализован еще, конечно, но я хочу знать, что это правильный вариант изменения для бассейна Пример игрока. Я могу представить себе следующие сценарии:

  1. Игрок имеет точно такие же методы, как класс Pool, которые что-то вроде

    public class Player 
    { 
        // something above 
        void setAvailablePool(Stats stat, int value){ statistics.pool.setAvailable(stat, value); } 
    } 
    

Это решение, кажется, хорошо, но тогда в классе игрока я бы много однострочных методов, которые просто перенаправляют заказы на сложенные поля.

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

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

ответ

1

Однострочные методы не являются проблемой, но то, что делает ваше решение № 1 неудовлетворительным, является нарушением Law of Demeter (statistics.pool.setXXXX). Возможно, лучше иметь метод statistics.setAvailableInPool() (или использовать вашу идею № 2). Я не могу больше помочь с конкретной реализацией, потому что не совсем понятно, что должны делать ваши классы Pool и Edge (или почему они настолько похожи друг на друга, но не реализуют общий интерфейс).

В ответ на ваш общий вопрос о создании интерфейсов для композиции взгляните на SOLID principles. В принципе, вы должны подумать о том, какие поведения вам нужны из ваших зависимостей, четко обозначить эти поведения и зависеть от интерфейса, а не от конкретного класса. Это упрощает понимание кода и упрощает его изменение в одном месте без необходимости изменять его везде.

+0

В основном они не реализуют общий интерфейс, потому что один из них имеет больше методов (Edge не имеет set/getAvailable). Что может быть связано с внедрением интерфейса в этом случае? Но у меня есть закон Деметра, но в этом случае у меня был бы такой же вопрос, как и выше. У меня есть Pool and Edge in Statistics, поэтому статистика должна иметь что-то вроде: setAvailablePool (int value) {pool.setAvailable (value); }. Та же проблема. –

+0

Мне кажется, что комментарии не могут быть изменены, поэтому я понял, почему я не использовал интерфейс на этот раз. Я просто не заинтересован в использовании, скажем, ссылок на ресурсы. Я просто не могу себе представить, почему я хотел бы сказать, что многие пулы и кромки хранятся в одном списке, как если бы ресурсы не предоставляли дополнительные методы пула Pool. Пул не работает так, как должен. –

+0

Возможно, вам удастся отследить реализацию некоторых функций, общих для 2 классов. В противном случае, похоже, вам нужно различать эти два. –

Смежные вопросы