手里拿着锤子，看啥都像钉子
2021-08-08 14:07:45

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

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

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

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

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

2.1 静态工厂

MessageFactory类
构造普通消息

public static MessageDTO buildCommonMsg(String topic, String msg) {

// 直接 new 然后 set 或者用 builder都可以
}

构造延时消息

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

顺序消息类似

 public static 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;

   // 提供全参构造方法
}

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

2.3 builder模式活用

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

对普通的 builder 模式稍微改造下，将必备参数作为 Builder 的唯一构造函数的参数。
这样必备属性必然会传入。
但是如果必传参数太多，不推荐使用这种方式。

哪怕是不同的 builder 模式，在 build时进行参数校验。

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

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

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

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

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

如果想在开发中少趟坑，感兴趣可以看看我最近出的几个 GitChat:

• 《程序员进阶之排错和避坑方法论》
• 《CodeReview 的正确姿势》