设计模式的选择 - 连续执行

时间:2017-06-18 18:45:25

标签: java spring design-patterns jaxb

我有一个简单的设计问题 - 我正在寻找实现简单功能的最佳模式。让我们说,我将在java中创建一个xml消息。此消息由不同逻辑组中的许多字段组成。

所以,第一个想法 - 创建一个类来设置所有字段。我可以做一个方法(这将是非常长的...)或将方法拆分为多个较小的(对于每个逻辑组)。但是,我认为这不是一个好方法,因为这个课程真的很长很难保持。

第二个想法是为不同的组创建一个功能接口和一些实现,例如GroupXxxSetter,GroupYyySetter等。我可以创建并保留列表或集合中的所有实例,并调用接口内定义的方法存储在集合中的对象。它似乎与“责任链”模式非常相似。但是,这种模式的想法是不同的,所以我不确定在我的情况下使用这种模式是否是个好主意。

我应该在这里使用“责任链”模式吗?或者,也许有更好的东西?

提前致谢。

1 个答案:

答案 0 :(得分:0)

  

我应该在这里使用“责任链”模式吗?

显然,没有。您没有负责回应请求的候选人的概念。所有元素都将进行处理。

  

或者,也许有更好的东西?

您有多种可能性 您的上下文并未完全设定。因此很难提出一个而不是另一个。

我可以建议您使用Builder模式(Java Effective reference而不是GOF)实现。

对于每个逻辑组,您可以拥有一个特定的类 您还将拥有一个由逻辑组实例组成的复合类。

您可以在每个逻辑组类中使用Builder模式,而在复合类中使用相同类型的Builder模式,而不是提供可防止不可变性且可以使规则验证变得繁琐的公共构造函数或setter。您将从先前创建的逻辑组实例构建最终消息。

您可以这样创建实例:

OneLogicGroup oneLogicGroup = OneLogicGroup.builder().fieldXXX(...).fieldYYY(...).build();

AnotherLogicGroup anotherLogicGroup = AnotherLogicGroup .builder().fieldXXX(...).fieldYYY(...).build();

MyMessage myMessage = MyMessage.builder().oneLogicGroup(oneLogicGroup).anotherLogicGroup(anotherLogicGroup).build().
  

我可以创建并保留列表或集合中的所有实例并调用   在接口内部为每个存储在内的对象定义的方法   集合。

似乎是指结构性问题 它与对象的创建没有直接关系。它与如何共享创建的对象有很大关系。
flyweight模式满足了这种需求,可以与呈现的构建器模式一起使用。