Шаблон параметризованной стратегии

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

interface Strategy {
     public data execute(data);
}

class StrategyA implements Strategy {
     public data execute(data);
}

class StrategyB implements Strategy {
      public StrategyB(int paramA, int paramB);
      public data execute(data);
}

class StrategyC implements Strategy {
      public StrategyC(int paramA, String paramB, double paramC);
      public data execute(data);
}

Теперь я хочу, чтобы пользователь мог вводить параметры в каком-то пользовательском интерфейсе. Пользовательский интерфейс следует выбирать во время выполнения, т. е. стратегии не должны от него зависеть. Диалоговое окно параметров не должно быть монолитным, и должна быть возможность заставить его вести себя и выглядеть по-разному для каждой стратегии и пользовательского интерфейса (например, консоли или Swing).

Как бы вы решили эту проблему?


java oop design-patterns model-view-controller strategy-pattern
person Community    schedule 18.04.2010    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Одна из возможностей сделать это с помощью чего-то похожего на шаблон проектирования Builder:

Для каждого типа стратегии у вас должен быть соответствующий конструктор (один или несколько). Построитель не работает как обычный построитель, получая все параметры инициализации в качестве аргументов метода; Вместо этого он должен блокироваться до тех пор, пока не будет получен соответствующий ввод. Некоторые компоновщики будут отображать диалоговое окно Swing и ждать, другие будут печатать на консоли и ждать входных данных, третьи могут читать из файла и т. д. После того, как компоновщик получит все входные данные, он может создать экземпляр стратегии и вернуть его.

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

person Eyal Schneider    schedule 18.04.2010
comment
+1 Другими словами, сами строители были бы стратегиями. Ницца. - person Péter Török; 18.04.2010

arrow_upward
1
arrow_downward

Решение этой проблемы зависит главным образом от того, что определяет, какая стратегия является текущей. Для простоты я предполагаю, что пользовательский интерфейс одинаков для всех стратегий.

Практически вы будете создавать класс строителя или фабричный метод. Что-то в этом роде:

interface StrategyPicker {
    public Strategy getStrategy();
}

// Most likely used in the JFrame it is added to
class StrategyPickerUI extends JPanel implements StrategyPicker {
    // initialize the panel with all the widgets
    // and implement the getStrategy method. the getStrategy
    // method should be called after the input is done in this
    // panel (such as clicking an Ok or Apply button)
}

// You can also make one for the console app
class StrategyPickerSimple implements StrategyPicker {
    // ...
}

Если вы хотите быть по-настоящему модным, вы создаете простой фабричный класс, чтобы удалить акт создания в свой собственный класс:

public class StrategyFactory() {
    public static Strategy createStrategyFromParameters(StrategyParams sp) {
        // creates the Strategy object... doesn't need to be public static
        // and if it isn't, it will help making unit tests easier
    }

    // This nested class could be split up to StrategyAParams, 
    // StrategyBParams, StrategyCParams
    public class StrategyParams {
        data paramA; 
        int paramB_A;
        int paramB_B;
        int paramC_A;
        String paramC_B;
        float paramC_C;
    }
}

// in StrategyPickerUI class
    public getStrategy() {
        StrategyParams sp = new StrategyParams();
        sp.paramB_A = myJTextFieldParamB_A.getText();
           // and so on...
        return StrategyFactory.createStrategyFromParameters(sp);
    }

Если вы хотите, чтобы пользовательский интерфейс не был монолитным, то разделите обязанности между их собственными объектами. Надеюсь это поможет.

person Spoike    schedule 18.04.2010

arrow_upward
0
arrow_downward

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

Будет сложнее создать пользовательский интерфейс для составных объектов и набора параметров.

Взгляните на Metawidget, это мощный генератор пользовательского интерфейса.

person Guillaume    schedule 05.05.2010