0

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

在示例中，这段代码有异味吗？我应该只传递需要的参数还是传递我需要的数据的模型/bean。

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

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();
}

另一个问题：在编写可测试代码时，您是否倾向于编写太多类。有太多类或一个类有太多方法是错误的。这些类很有用并且只有一个目的。但是，我可以看到它们可以在哪里重构为一个更大的类……但是那个类有多种用途。

4

3 回答 3

3

您还会注意到 Misko Hevery 建议在参数数量增加或在逻辑上可接受的情况下将参数分组到类中。

所以在你的情况下，你可以SourceCodeBean毫无悔意地通过。

于 2010-01-07T14:50:55.037 回答
0

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

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

通常，如果参数不是太多，我更喜欢将参数传递给构造函数。Code Complete 建议最多使用 7 个参数。如果您发现构造函数参数的数量很麻烦，您总是可以从前面提到的 SourceCodeParser 类中创建 setter。

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

于 2010-01-07T14:51:44.567 回答
0

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

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

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

于 2010-01-07T15:11:20.253 回答