这可能是一个相当主观的问题,但我想知道更多的意见。我使用 Spring MVC 构建了 Rest API 服务,并实现了 DTO-域-实体模式。我想知道您对实施该法案有何看法建造者模式 https://en.wikipedia.org/wiki/Builder_pattern在 DTO 中,类似
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,我想不出任何构造复杂对象的例子。
构建器模式是有助于使不可变对象更易于使用并增加代码清晰度的模式之一。
构建器模式提供对象的不变性。然后,我们可以认为 DTO 是服务响应本身,不应更改,因为这是响应(至少我是这么想的)
所以你怎么看?我应该在 DTO 中使用这种模式吗(考虑到这种情况,可能是大多数情况,不满足复杂对象原则)?
我的简短回答是,这是一个偏好问题。如果您喜欢构建器模式的工作方式,请应用它。对于这么小的一个案例,我认为这都不重要。我个人的偏好是不要在这里使用 Builder,因为它似乎没有增加太多价值。
我的较长答案是,构建器模式旨在促进复杂对象的更轻松配置,而无需诉诸诸如伸缩构造函数之类的反模式。在这种情况下,在任何一种情况下都没有反模式;这两种选择都相对较小且有效。
不过,当我们谈论偏好时,我更喜欢使用流畅界面的构建器模式的修改版本;每个方法都返回 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();
再次强调,这只是个人喜好问题。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)