Question

我有实体Reward可以给予玩家奖励。

因此，当满足所有条件时，调用方法executeReward();

问题是：实施可能非常不同。例如，Reward可以向玩家提供资金，或者开始全球事件，或者向玩家提供另一个任务（与之前无关）。即我不知道将执行什么逻辑。这怎么设计？在模型和服务之间的沟通方面。

我在考虑的选项：

创建奖励服务，从executeReward(RewardService rs)方法调用不同的方法，但这会打破“模型不知道服务”。
在服务层中编排逻辑。但这需要手动映射，这会破坏域中层次结构的整个目的。

似乎都没有好的选择。这样做有好办法吗？

ps：通过休眠从DB获取奖励实体。因此，由于hibernate没有插入服务而出现复杂性（可能）。也就是说，实体通常应该避免提供服务，AFAIK。

Answer 1

解决方案1 

我会通过Command behavioral design pattern实现奖励逻辑。

E.g。使用一个Reward方法引入常见的execute接口，并在其实现时封装各种奖励：MoneyReward，QuestReward等。每个特定的实现都应该得到所有需要在创作过程中执行：

class MoneyReward implements Reward {
   MoneyReward(Player gamer, Depository money) {
      ...
   }
   @Override 
   public execute() {
      ...
   }
}
...
class QuestReward implements Reward {
   MoneyReward(Player gamer, Map territory) {
      ...
   }
   @Override 
   public execute() {
      ...
   }
}

根据您的条件选择所需的Reward实体后，您只需获得奖励：

Raward gift = ...
gift.execute();

解决方案2

或者可以使用Strategy behavioral design pattern。

E.g。 Reward界面可能看起来像这样

interface Reward {
   void execute(Player gamer);
}

其中一个可能的实现是

class MoneyReward implements Reward {
   MoneyReward(Depository money) {
      ...
   }
   @Override 
   public execute(Player gamer) {
      ...
   }
}

此处MoneyReward命令和策略之间有什么区别？

该命令封装了在创建过程中执行所需的所有操作，并且可以针对特定游戏玩家使用一次。每次想要奖励时，您都需要创建MoneyReward命令实例。

相反的MoneyReward策略仅封装了在所有玩家中进行重写所需的常用服务。 MoneyReward策略可以创建一次（例如像Spring单例）并在所有应用程序生命周期中重用。

两个解决方案Depository，Map，Player中的

注意：应该是未定义的小型接口，而不是Single Responsibility Principle。

如何设计模型和服务之间的交互？

1 个答案: