Структурирование механизма правил

#java #oop #design-patterns

Вопрос:

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

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

  • Игрок
  • Сущность
  • Сервер

Позже они будут использованы для создания таких условий, как «Проверка Player has been connected this week «.

Зная это, я думаю, что у меня должно быть какое-то interface имя ConditionExecutor , которое будет содержать цель? У каждого условия также должен быть метод execute, который будет вызван, чтобы проверить, выполнено условие или нет, и именно здесь все становится запутанным для меня.

Допустим , у меня есть интерфейс ConditionExecutor , я думаю, что мне также понадобится PlayerConditionExecutor для всех исполнителей, связанных с игроками, но это только интерфейсы (я думаю, что они должны быть).

Тогда у меня были бы реальные классы, которые будут обрабатывать каждое условие. Например, что-то вроде:

 public class PlayerOnlineExecutor implements PlayerConditionExecutor {
    private ConditionExecutionType conditionExecutionType = ConditionExecutionType.PLAYER_ONLINE_STATUS;
    public boolean execute(Player player) {
        return player.isOnline();
    }
}
 

Этот исполнитель тогда был бы где-то зарегистрирован, но я все еще не понимаю, как я могу это структурировать.
Условие, показанное выше, довольно простое, но могут потребоваться дополнительные данные, подобные этому:

 public class PlayerHoursPlayedExecutor implements PlayerConditionExecutor {
    private ConditionExecutionType conditionExecutionType = ConditionExecutionType.PLAYER_PLAYED_TIME;

    public boolean execute(Player player, int hoursThreshold) {
        return player.getTotalTimePlayed() >= hoursThreshold;
    }
}
 

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

I would finally have a manager ConditionsManager which will then retrieve all the conditions based on the condition type (see example above) and execute each condition. The issue is that each condition may require a different target (player, entity, server,…) and could require a bunch of different metadata.

If anyone could bring me in the good direction, or show me certain design patterns that may be useful here, would be awesome.

PS: В приведенных выше примерах вы увидите PlayerConditionExecutor и ConditionExecutor , вот они, но я думаю, что они ошибаются:

 public interface PlayerConditionExecutor extends ConditionExecutor {
    <T> boolean execute(Player p, T ...args);
}
 
 public interface ConditionExecutor<T> {
    <A> boolean execute(T target, A ...args);
}