一、背景

有人在我的构造器文章下提了下面一个问题：

老师，提一个问题，在实际生活中遇到的 比如说我写了一个发送消息的方法。比如说有一个参数是 messageDTO，但是他有很多属性，比如说 topic，tag，shadingKey，msg， delayTime 等等，但是我希望别人在使用这个方法的时候传入 messageDTO 是我想要的，即我会将无参构造方法私有化，因为我不想让别人使用无参构造new一个对象出来，（因为自己去set可能某一些参数设置有遗漏），然后只限制了 几种构造函数，或者使用静态方法来创建对象。
然后对象的入参是由要求的。比如说你想法 普通消息，那么需要 topic和msg，发延迟消息，需要topic msg和delayTime，发顺序消息需要额外再加一个shadingKey，请问在这种情况下如何使用建造者模式。即只允许使用某一组参数来创建对象

二、探索

每种设计模式（甚至任何技术）都有自己适合的场景。
虽然我们学了建造者模式，未必一定要用建造者模式。

针对这种场景，有很多方法可以更优雅地实现：

• 可以使用工厂模式，通过函数名体现类型。
• 可以通过继承的方式通过类名来体现类型。
• Builder 模式变通

2.1 对象构造工程

构造普通消息

public MessageDTO buildCommonMsg(String topic, String msg) {  
  
// 直接 new 然后 set 或者用 builder都可以  
}  

构造延时消息

 public MessageDTO buildDelayMsg(String topic, String msg,Long delayTime) {  
// 省略  
 }  

顺序消息类似

 public MessageDTO buildOrderedMsg(String topic, String msg, String shadingKey)   
{  
    // 省略  
 }  

2.2 利用继承来表意

普通消息 CommonMsgDTO

public class CommonMsgDTO{  
  private String topic;  
  private String msg;  
  
   // 提供全参构造方法  
}  

延时消息 DelayMsg

public class DelayMsgDTO extends CommonMsgDTO{  
  private Long delayTime;  
  
   // 提供全参构造方法  
}  

顺序消息 DelayMsg

public class OrderedMsgDTO extends CommonMsgDTO{  
  private String shadingKey;  
  
   // 提供全参构造方法  
}  

这样构造时只有全参数构造函数，就不容易传错，而且看名知意。

2.3 builder模式活用

public static class Builder{  
 // 省略
 public Builder(String topic, String msg){
// 省略
}
// 其他属性的set 方法
}  

对普通的 builder 模式稍微改造下，将必备参数作为 Builder 的唯一构造函数的参数。
这样必备属性必然会传入。

可能还有很多解决方案，上面给出两个比较简单且常见的方法。
在执行发送消息的函数上加上参数校验，这样就不容易出错。

三、总结

希望大家一定要破除 ”手里拿着锤子，看啥都像钉子“的心理。
在学习任何技术时，思考其最适合的场景，为了解决什么问题，局限是什么。

在解决问题前想清楚问题是什么？

比如这位同学核心是为了能让使用者清晰地区分类型，然后让使用者知道不同类型的参数差异。
然后再去思考怎样更容易区分开呢？必传参数一定要早构造的时候校验吗？
慢慢地，问题就明了了，就更容易得到更科学的答案。

总之，既要埋头苦学，又要抬头看路。学而不思则罔！

欢迎关注本人的慕课专栏：

再学经典：《Effective Java》独家解析

解锁大厂思维：剖析《阿里巴巴 Java 开发手册》