这可能是一个非常主观的问题,但我想知道一些更多的意见。我用Spring MVC构建了一个Rest API服务,并实现了DTO-Domain-Entity模式。我想知道您在DTO中实现Builder pattern的想法,比如
public class UserResponseDTO
extends AbstractResponseDTO {
private String username;
private Boolean enabled;
public UserResponseDTO(String username, Boolean enabled) {
this.username = username;
this.enabled = enabled;
}
public String getUsername() {
return this.username;
}
public Boolean getEnabled() {
return this.enabled;
}
public static class Builder {
private String username;
private Boolean enabled;
public void setUsername(String username) {
this.username = username;
}
public void setEnabled(Boolean enabled) {
this.enabled = enabled;
}
public UserResponseDTO build(){
return new UserResponseDTO(username, enabled);
}
}
}
根据定义:
Builder设计模式的目的是将复杂对象的构造与其表示分开。通过这样做,相同的构造过程可以创建不同的表示。
在我的大多数DTO案例中(不是说所有案例)我都没有更复杂的对象来构建,例如这种情况。老实说,如果我们谈论DTO,我想不出构建复杂对象的任何例子。
有助于使不可变对象更易于使用并增加代码清晰度的模式之一是Builder模式。
Builder模式为对象提供了不可变性。然后,我们可以认为DTO是服务响应本身,不应该被改变,因为这是一个响应(至少这是我如何思考)
那你觉得怎么样?我是否应该将此模式用于DTO(考虑到这种情况,并且可能大多数情况下,它们不满足复杂对象原则)?
答案 0 :(得分:12)
我的简短回答是,这是一个偏好问题。如果您喜欢Builder Pattern的工作方式,请应用它。对于这么小的案例,我认为无论如何都不重要。我个人的偏好是不要在这里使用Builder,因为它似乎没有增加太多价值。
我更长的答案是,Builder Pattern旨在简化复杂对象的配置,而无需使用像telescoping构造函数这样的反模式。在这种情况下,你不会在任何一种情况下都有反模式;两种选择都相对较小且效率很高。
虽然我们正在谈论偏好,但我更喜欢使用流畅界面的修改版构建器模式;每个方法返回Builder的实例,以便方法调用可以链接在一起(而不是在单独的行上)。这类似于您链接的文章中的Java示例。
我修改您的构建器看起来像这样:
public static class Builder {
private String username;
private Boolean enabled;
public Builder setUsername(String username) {
this.username = username;
return this;
}
public Builder setEnabled(Boolean enabled) {
this.enabled = enabled;
return this;
}
public UserResponseDTO build(){
return new UserResponseDTO(username, enabled);
}
}
因此,使用构建器看起来像这样:
UserResponseDTO ur = new Builder().setUsername("user").setEnabled(true).build();
再次,只是个人偏好的问题。