Question

根据具有可测试性博客的Misko Hevery的说法。开发人员应避免使用“持有者”，“上下文”和“厨房接收器”对象（这些对象采用各种其他对象，并且是合作者的抓包）。传递您需要的特定对象作为参数，而不是该对象的持有者。

在示例中，这个代码闻到了吗？我应该只传递所需的参数还是模型/ bean以及我需要的数据。

例如，你会做这样的事情：注意。我可能已经将数据作为构造函数args传递。这是代码味吗？

public Parser {
  private final SourceCodeBean source;

  public Parser(final SourceCodeBean s) {
    this.source = s;
  }

  public void parse() {
     // Only access the source field
     this.source.getFilename();
     ...
     ... assume that the classes uses fields from this.source
     ...
  }

}

public SourceCodeBean {
   private String filename;
   private String developer;
   private String lines;
   private String format;

   ...
   ...
   <ONLY SETTERS AND GETTERS>
   ...
}

...

Or 

public Parser {


  public Parser(String filename, String developer, String lines ...) {
    ...
  }

}

And building a test case

public void test() {
  SourceCodeBean bean = new SourceCodeBean():
  bean.setFilename();

  new Parser().parse();
}

另一个问题：编写可测试代码时，您是否倾向于编写太多类。有太多的类或一个类有太多方法的类是不对的。这些类很有用，只有一个目的。但是，我可以看到它们可以被重构成一个更大的类......但是这个类有多种用途。

Answer 1

您还会注意到，Misko Hevery建议在参数计数增加时或在逻辑上可接受的情况下，在类中对参数进行分组。

因此，在您的情况下，您可以毫无悔意地传递SourceCodeBean。

Answer 2

你要问的很多都是非常主观的，如果你不知道你想要完成什么的全部范围，很难提出有用的建议，但这是我的2美分。

我会选择你的后一种设计。创建一个名为SourceCodeParser的类，让构造函数接受文件名，开发人员等，并让它有一个解析方法。这样，对象负责解析自己。

通常我更喜欢将参数传递给构造函数，如果它们不是太多。代码完成建议最多7个参数。如果你发现构造函数参数的数量很麻烦，你总是可以在前面提到的SourceCodeParser类中创建setter。

如果您想要一种方法来实现不同的解析行为，我建议在SourceCodeParser中使用Parser委托，并将其作为构造函数参数或setter传入。

Answer 3

如果你的课程的唯一目的是将各种信息联系在一起，那么我认为没有理由不将该课程直接用作参数。原因是该类被编码为完全正确，所以为什么你不让它做它的工作呢？所以我肯定更喜欢前者。

现在，假设Parser实际上需要信息，因为它在SourceCodeBean中以语义方式呈现。如果所有Parser实际需要的是文件名，那么它应该只取文件名，我更喜欢第二种方法。

我认为这里唯一让我担心的是SourceCodeBean成为一种信息的“厨房下沉”。例如，文件名和格式字段在这里非常有意义。但你真的需要开发人员和线路吗？那些可以改为某种相关的元数据信息类吗？

可测试的Java代码：使用带有构造函数的模型bean

3 个答案: