我们的代码库是新老程序员，像我自己一样，为了统一起见，他们很快就学会了按照做事的方式来做。考虑到我们必须从某个地方开始，我自己决定重构一个数据持有者类，如下所示：

• 删除了setter方法，并设置了所有字段final（我final理所当然地认为“ 好”）。事实证明，该二传手仅在构造函数中使用，因此没有副作用。
• 引入了一个Builder类

Builder类是必需的，因为构造函数（首先是提示重构的原因）跨越大约3行代码。它有很多参数。

幸运的是，我的一个团队的成员正在另一个模块上工作，并且碰巧需要设置者，因为他需要的值在流程的不同点可用。因此，代码如下所示：

public void foo(Bar bar){
    //do stuff
    bar.setA(stuff);
    //do more stuff
    bar.setB(moreStuff);
}

我认为他应该改用构建器，因为摆脱设置器可以使字段保持不变（他们之前听说过关于不变性的内容），并且还因为构建器允许对象创建是事务性的。我草绘了以下伪代码：

public void foo(Bar bar){
    try{
        bar.setA(a);
        //enter exception-throwing stuff
        bar.setB(b);
    }catch(){}
}

如果引发该异常，bar将有损坏的数据，而使用构建器可以避免：

public Bar foo(){
        Builder builder=new Builder();
    try{
        builder.setA(a);
        //dangerous stuff;
        builder.setB(b);
        //more dangerous stuff
        builder.setC(c);
        return builder.build();
    }catch(){}
    return null;
}

我的队友反驳说，有问题的异常永远不会触发，对于特定的代码区域来说这是公平的，但是我相信缺少树的森林。

折衷方案是恢复到旧的解决方案，即使用无参数的构造函数，并根据需要使用setter设置所有内容。理由是该解决方案遵循了我的违反的KISS原则。

我是这家公司的新手（不到6个月），并且完全意识到我失去了这家公司。我的问题是：

• 是否还有另一个争论来使用Builders而不是“旧方法”？
• 我提出的变更真的值得吗？

但是真的

• 在提倡尝试新事物时，您有什么技巧可以更好地表达这些论点？

考虑到我们必须从某个地方开始，我自己决定重构一个数据持有者类

这是错误的地方-您对代码库进行了重大的体系结构更改，以使其与预期的变得截然不同。您使您的同事感到惊讶。惊喜只有在参加聚会时才是好的，最少惊喜的原则是黄金（即使涉及聚会，我也会穿干净的内裤！）

现在，如果您认为此更改值得，那么最好草绘出显示该更改的伪代码，并将其呈现给您的同事（或至少是角色最接近架构师的人），然后在做任何事情之前先看看他们的想法。实际上，您很无赖，以为整个代码库都是您认为合适的。团队成员，而不是团队成员！

我可能对您有点苛刻，但我却处在相反的位置：检查一些代码并认为“ WTF发生在这里？！”，才发现新人（几乎总是新人）决定改变根据他认为的“正确方法”应该做的事情。还要与SCM历史保持一致，这是另一个主要问题。

幸运的是，我的一个团队的成员正在另一个模块上工作，并且碰巧需要设置者，因为他需要的值在流程的不同点可用。

如前所述，我看不出是什么使代码需要设置程序。我可能对用例不太了解，但是为什么不等到实例化对象之前知道所有参数呢？

作为替代方案，如果情况需要使用setter：提供一种冻结代码的方法，如果尝试在对象准备好后修改字段，则setter会引发断言错误（aka程序员错误）。

我认为除去二传手并使用final是做到这一点以及加强不变性的“适当”方法，但是，这真的是您应该花费的时间吗？

一般提示

老=坏，新=好的，我的方式，您的方式...这种讨论不是建设性的。

当前，对象的使用方式遵循一些隐式规则。这是您未编写代码的规范的一部分，您的团队可能认为代码的其他部分滥用它的风险不大。您要做的是通过Builder和编译时检查使规则更加明确。

在某种程度上，代码重构与“ 残破的窗口”理论联系在一起：您认为正确解决任何问题是正确的（或为以后的“质量改进”会议做笔记），以便使代码始终看起来令人愉快，安全干净。但是，您和您的团队对“足够好”有不同的想法。您认为与真诚的团队一起做出贡献，使代码更好的机会可能与现有团队有所不同。

顺便说一句，你的球队不应该被假定为从惯性，不良的生活习惯进行一定的痛苦，缺乏教育，...你可以做的最糟糕的是投射的图像无所不知的一切谁在那里向他们展示如何编码。例如，不变性并不是什么新鲜事物，您的同龄人可能已经读过它，而仅仅是因为这个话题在博客中变得越来越流行，还不足以说服他们花时间更改其代码。

毕竟，有无数种方法来改进现有的代码库，但是却要花费时间和金钱。我可以看一下您的代码，将其称为“旧的”，然后找一些事情进行讨论。例如：没有正式的规范，没有足够的断言，也许没有足够的注释或测试，没有足够的代码覆盖率，算法不理想，内存使用过多，在每种情况下均未使用“最佳”可能的设计模式，等等。ad nauseam。但是对于大多数我想提的要点，您会认为：没关系，我的代码有效，无需花更多时间在上面。

也许您的团队认为您的建议已经超出了收益递减的范围。即使由于示例的原因而发现了一个错误的实际实例（例外），他们也可能只修复了一次并且不希望重构代码。

因此，问题是鉴于他们有限，该如何度过您的时间和精力？软件会不断进行更改，但是通常您的想法会以负数开始，直到您可以为其提供良好的论据为止。即使您对收益是正确的，但这本身也不是一个充分的论据，因为它将在“ 有一天，很高兴…… ”篮子中结束。

在提出论据时，您必须进行一些“理智”检查：您是要出售自己的想法还是自己？如果其他人向团队提出了该怎么办？您会在他们的推理中发现一些缺陷吗？您是要应用一些通用的最佳实践还是要考虑代码的细节？

然后，如果要解决团队过去的“错误”，请确保不会出现。它有助于表明您不是您的主意，但可以合理地获得反馈。您做得越多，您的建议就越有机会被遵循。

如何在团队中促进使用Builder模式？

你不知道

如果您的构造函数具有3行参数，则它太大且太复杂。没有设计模式可以解决此问题。

如果您有一个其数据在不同时间可用的类，则它应该是两个不同的对象，或者您的使用者应聚合这些组件，然后构造该对象。他们不需要建造者来做到这一点。

您似乎更注重做对而不是与他人合作。更糟糕的是，您意识到自己正在做的是一场权力斗争，却没有考虑到经历和权威受到挑战的人们可能会感觉如何。

反过来。

专注于与他人合作。将您的想法整理为建议和想法。在提出问题之前让他们讨论他们的想法，以使他们思考您的想法。避免直接对抗，并外在愿意接受与小组进行艰难的战斗来改变小组相比，继续做小组的事情（目前而言）更具生产力。（尽管把事情带回去。）使与您一起工作变得愉快。

始终如一地这样做，应该减少冲突，并发现更多的想法被他人采纳。我们所有人都遭受这样的幻想：完美的逻辑论证会让别人赞叹并赢得胜利。而且，如果这种方式行不通，我们认为应该。

但这与现实直接冲突。在提出第一个逻辑要点之前，大多数参数都会丢失。即使在所谓的逻辑人物中，心理学也胜过理性。说服人们的目的在于克服心理障碍，使其得到正确的聆听，而不是拥有完美的逻辑。

是否还有另一个争论来使用Builders而不是“旧方法”？

“当您有了新的锤子时，一切都会看起来像钉子。” -这就是我读到您的问题时的想法。

如果我是你的同事，我会问你“为什么不在构造函数中初始化整个对象？” 毕竟这就是功能。为什么要使用构建器（或任何其他设计）模式？

我提出的变更真的值得吗？

从那个小的代码片段很难分辨出来。也许是-您和您的同事需要对其进行评估。

在提倡尝试新事物时，您有什么技巧可以更好地表达这些论点？

是的，在讨论该主题之前，请详细了解该主题。在进行讨论之前，请以良好的论据和理由武装自己。

我当时因技能而应聘。当我必须查看代码时，..那就太可怕了。然后尝试清理它时，去过那里的人总是抑制更改，因为他们看不到好处。听起来像您正在描述的东西。最终我辞去了该职位，现在我可以在一家拥有更好实践的公司中发展得更好。

我认为您不应该与团队中的其他人一起发挥作用，因为他们在那里待了更长的时间。如果您看到您的团队成员在您所从事的项目中使用了不良做法，则必须像现在一样指出imo。如果没有，那么您就不是非常宝贵的资源。如果确实要一遍又一遍地指出这些问题，但没有人在听，请向您的管理层要求更换或更换工作。非常重要的一点是，不要让自己适应不良做法。

对实际问题

为什么要使用不可变的对象？因为您知道您要处理的内容。

假设您传递了一个数据库连接，该数据库连接允许您通过设置器更改主机，那么您不知道它是什么连接。由于是一成不变的，所以您知道。

但是，假设您具有一个可以从持久性中检索然后再使用新数据重新持久化的数据结构，则可以认为该结构不是不变的。它是同一实体，但是值可以更改。而是使用不可变值对象作为参数。

但是，您要重点关注的问题是一种构建器模式，以摆脱构造器中的依赖关系。我对此表示不满。实例显然已经很复杂了。不要试图隐藏它，解决它！

l

删除安装员可能是正确的，具体取决于类别。构建器模式不能解决问题，而只是将其隐藏。（即使您看不见，地毯下的污垢仍然存在）

尽管所有其他答案都非常有用（比我的要有用的多），但是还有一个您尚未提到的构建器的属性：通过将对象的创建转换为流程，您可以强制执行复杂的逻辑约束。

例如，您可以要求将某些字段设置在一起或以特定的顺序设置。您甚至可以根据这些决定返回目标对象的不同实现。

// business objects

interface CharRange {
   public char getCharacter();
   public int getFrom();
   public int getTo();
}

class MultiCharRange implements CharRange {
   final char ch;
   final int from;
   final int to;

   public char getCharacter() { return ch; }
   public int getFrom() { return from; }
   public int getTo() { return to; }
}

class SingleCharRange implements CharRange {
   final char ch;
   final int position;

   public char getCharacter() { return ch; }
   public int getFrom() { return position; }
   public int getTo() { return position; }
}

// builders

class Builder1 {
   public Builder2 character(char ch) {
      return new Builder2(ch);
   }
}

class Builder2 {
   final char ch;
   int from;
   int to;

   public Builder2 range(int from, int to) {
      if (from > to) throw new IllegalArgumentException("from > to");
      this.from = from;
      this.to = to;
      return this;
   }

   public Builder2 zeroStartRange(int to) {
      this.from = 0;
      this.to = to;
      return this;
   }

   public CharRange build() {
      if (from == to)
         return new SingleCharRange(ch,from);
      else 
         return new MultiCharRange(ch,from,to);
   }
}

这是一个毫无意义的示例，但它演示了所有三个属性：始终始终设置字符，始终将范围限制设置并验证，并且在构建时选择实现。

很容易看出这如何导致更易读和可靠的用户代码，但是如您所见，它还有一个缺点：很多构建器代码（我什至省去了构造器以缩短代码片段）。因此，您尝试通过询问以下问题来计算权衡：

• 我们仅从一两个地方实例化对象吗？这有可能改变吗？
• 也许我们应该通过将原始对象重构为较小对象的组合来实施这些约束？
• 我们最终会在方法之间传递构建器吗？
• 我们可以改用静态工厂方法吗？
• 这是外部API的一部分吗，需要尽可能地做到万无一失？
• 如果有构建器，大约可以避免我们当前积压的bug数量？
• 我们将节省多少额外的文档编写工作？

您的同事只是认为权衡是没有好处的。您应该公开和诚实地讨论原因，最好不要诉诸抽象原则，而应专注于此解决方案的实际含义。

听起来这个类实际上是一个以上的类，并放在同一文件/类定义中。如果它是DTO，则应该可以一次性实例化它并且使其不可变。如果您在任何一项交易中都不使用所有字段/属性，那么几乎可以肯定它会打破“单一责任”原则。可能是将其分解为更小，更紧密，不可变的DTO类可能会有所帮助。如果您还没有读干净代码，请考虑阅读它，以便更好地阐明问题以及进行更改的好处。

我认为您不能按委员会在此级别上设计代码，除非您确实是暴民编程（这听起来不像您属于那种团队），所以我认为可以根据您的要求进行更改最好的判断，如果事实证明您判断不对，就把它放在下巴上。

但是，只要您能够按原样阐明代码的潜在问题，那么即使您的解决方案不是公认的解决方案，您仍然可以争论是否需要解决方案。然后人们可以自由地提供替代方案。

“ 强硬见解，软弱无力 ”是一个好原则-您可以根据自己的知识来自信地前进，但是如果您发现一些与之相反的新信息，则应谦虚而退缩，并就正确的解决方案进行讨论。是。唯一的错误答案是让它变得更糟。