OO上的JavaWorld：Getters / Setters与Builder

Question

背景：

我在JavaWorld上找到了这篇文章，其中Allen
Holub解释了Getters / Setters的替代方法，该替代方法保留了应隐藏对象的实现的原理（他的示例代码也可以在下面找到）。

据介绍，该班Name/ EmployeeId/ Money应该有一个构造函数取一个字符串-
推理是，如果你作为一个键入它int，后来需要将其更改为一个long，你将不得不修改类的所有用途，以及使用这种模式，您不必。

问题1：

我在想：这难道不只是将问题转移到要处理的String参数解析上吗？例如，如果所有使用EmployeeId（从接收到Exporter）的代码都将解析String为int，然后突然开始导出long值，则您需要修改的用途完全相同…如果您开始解析它，long则可能更改为double（即使对于id来说，这毫无意义）…，如果您不确定要解析的内容String，
就什么也不能实现 。

问题2：

除了这个问题，我还有一个问题：我意识到这篇文章已有七年历史了，所以有人能指出我有关OO设计的最新概述，特别是有关吸气剂/设置剂和实现隐藏辩论的想法吗？

清单1.员工：Builder上下文

  public class Employee
  {   private Name        name;
      private EmployeeId  id;
      private Money       salary;

      public interface Exporter
      {   void addName    ( String name   );
          void addID      ( String id     );
          void addSalary  ( String salary );
      }

      public interface Importer
      {   String provideName();
          String provideID();
          String provideSalary();
          void   open();
          void   close();
      }

      public Employee( Importer builder )
      {   builder.open();
          this.name   = new Name      ( builder.provideName()     );
          this.id     = new EmployeeId( builder.provideID()       );
          this.salary = new Money     ( builder.provideSalary(),
                                    new Locale("en", "US") );
          builder.close();
      }

      public void export( Exporter builder )
      {   builder.addName  ( name.toString()   );
          builder.addID    ( id.toString()     );
          builder.addSalary( salary.toString() );
      }

      //...
  }

Answer 1

问题1
：字符串解析似乎很奇怪。恕我直言，您只能做很多事来期待将来的增强。您可以long从一开始就确定使用参数，或者稍后考虑添加其他构造函数。或者，您可以引入可扩展参数类。见下文。

问题2 ：在几种情况下，构建器模式可能有用。

• 复杂对象创建

当您处理具有许多属性的非常复杂的对象时，最好在对象创建时仅对其设置一次，使用常规构造函数执行此操作可能会变得难以阅读，因为构造函数将包含很长的参数列表。将其发布为API并不是一种好方法，因为每个人都必须仔细阅读文档，并确保不要混淆参数。

取而代之的是，当您提供一个构建器时，只需要处理带有所有参数的（私有）构造器，但是类的使用者可以使用可读性更高的单个方法。

设置器不是一回事，因为它们允许您在创建对象后更改对象属性。

• 可扩展的API

当您仅为您的类发布多参数构造函数，然后又决定需要添加新的（可选）属性（例如，在软件的更高版本中）时，您必须创建第二个与第一个相同的构造函数，但又需要一个参数。否则，如果只是将其添加到现有构造函数中，则会破坏与现有代码的兼容性。

使用构建器，您只需为新属性添加新方法，而所有现有代码仍然兼容。

• 不变性

软件开发正强烈趋向于并行执行多个线程。在这种情况下，最好使用无法创建的对象（不可变对象），因为这些对象不会导致来自多个线程的并发更新出现问题。这就是为什么不能使用setter的原因。

现在，如果要避免多参数公共构造函数的问题，那么将构建器作为非常方便的替代方法即可。

• 可读性（“ Fluent API”）

基于构建器的API可能非常易于阅读，如果构建器的方法命名巧妙，则可以编写出几乎像英文句子一样的代码。

通常，构建器是一种有用的模式，根据您使用的语言，对于API的提供者来说，它们要么真的很容易使用（例如Groovy），要么有点乏味（例如Java）。但是，对于消费者而言，它们可能同样容易。