Тестируемый Java-код: использование bean-компонентов модели с конструктором

Question

По словам Миско Хевери, у которого есть блог для тестирования. Разработчики должны избегать объектов «держатель», «контекст» и «кухонная раковина» (они берут все виды других объектов и представляют собой сумку соавторов). Передайте в качестве параметра нужный вам объект вместо держателя этого объекта.

В примере удара этот код пахнет? Должен ли я передавать только необходимые параметры или модель / бин с данными, которые мне нужны.

Например, сделаете ли вы что-нибудь подобное: Примечание. Я, вероятно, мог бы передать данные как аргументы конструктора. Это запах кода?

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

Вы также заметите, что Миско Хевери советует группировать параметры в классах всякий раз, когда количество параметров увеличивается или в случаях, когда это логически приемлемо.

Так что в вашем случае вы можете передать SourceCodeBean без угрызений совести.

Answer 2

Если у вас есть класс, единственной целью которого является объединение различных частей информации, то я не вижу причин, по которым этот класс не следует использовать непосредственно в качестве параметра. Причина в том, что класс был написан именно для этого, так почему бы вам не позволить ему делать свою работу? Поэтому я бы определенно предпочел первое.

Теперь, это предполагает, что Parser действительно нуждается в информации, так как она семантически представлена ​​в SourceCodeBean. Если все, что действительно нужно Parser, - это имя файла, тогда оно должно просто взять имя файла, и я бы предпочел второй метод.

Я думаю, что единственное, что может меня здесь беспокоить, это SourceCodeBean превращение в своего рода "кухонную раковину" информации. Например, поля имени файла и формата здесь имеют смысл. Но вам действительно нужны разработчик и линии? Могут ли они быть в каком-то связанном классе метаданных-информации?

Answer 3

Многое из того, что вы спрашиваете, очень субъективно, и трудно сделать полезные предложения, не зная всего объема того, что вы пытаетесь достичь, но вот мои 2 цента.

Я бы пошел с твоим последним дизайном. Создайте один класс с именем SourceCodeParser, попросите конструктор взять имя файла, разработчика и т. Д., И у него есть метод синтаксического анализа. Таким образом, объект отвечает за синтаксический анализ.

Обычно я предпочитаю передавать параметры конструктору, если они не слишком многочисленны. Code Complete рекомендует максимум 7 параметров. Если вы считаете количество параметров конструктора громоздким, вы всегда можете создать сеттеры из вышеупомянутого класса SourceCodeParser.

Если вам нужен способ установить другое поведение синтаксического анализа, я бы порекомендовал использовать делегат Parser внутри SourceCodeParser и передавать его как параметр конструктора или как установщик.