Как это влияет на тестируемость для ассоциаций, передаваемых в качестве параметров классу?

Question

Я работаю над проблемой дизайна ОО. Я постараюсь сосредоточиться на части, в которой я запутался, и объяснить это в тексте, а не предоставлять код.

У меня есть класс с именем SalesPolicy, который содержит список TaxPolicy. TaxPolicy - это абстрактный класс, который представляет налоговую политику с именем и налоговой ставкой в ​​качестве атрибутов. TaxPolicy содержит абстрактный метод с именем accept. Конкретные реализации TaxPolicy должны реализовывать метод accept и предоставлять логику для принятия решения о применимости TaxPolicy.

У меня есть другой класс под названием SalesEngine. SalesEngine имеет SalesPolicy, а SalesPolicy является одним из параметров конструктора SalesEngine. SalesEngine решает, применим ли TaxPolicy из списка TaxPolicy в SalesPolicy для элемента, или нет, вызывая метод accept, а затем рассчитывает налог соответствующим образом. Как объяснялось ранее, SalesPolicy содержит единственный атрибут, который представляет собой список TaxPolicy и метод для добавления в список.

Что мне нужно знать, так это то, что для класса SalesEngine можно использовать такой параметр, как SalesPolicy. Как это влияет с точки зрения тестируемого кода?

Answer 1

Я думаю, что прекрасно иметь такой сценарий:

public SalesEngine(SalesPolicy policy) { ... }

Где когда SalesEngine создается пользователь или тот, кто уже знает, что SalesPolicy что они хотят использовать.

Другой сценарий, который может быть полезным включить, - это случай, когда пользователь не знает, что SalesPolicy они хотят использовать в то время SalesEngine создается, что вы можете сделать, добавив конструктор по умолчанию и метод установки:

// default construtor
public SalesEngine() { ... }

// sets the sales policy
public void setSalesPolicy(SalesPolicy policy){ ... } 

Answer 2

Я согласен с ответом Хантера, что ваше описание звучит разумно (и что, в зависимости от того, как оно будет использоваться, может быть полезно разрешить добавление SalesPolicy позже). Поэтому здесь я отвечу на ваш вопрос о тестировании. Короткий ответ: на самом деле это мало что меняет.

Предполагая, что SalesEngine нуждается в объекте SalesPolicy, чтобы выполнить свою задачу, он должен получить его так или иначе. Предположительно, трудности в тестировании будут заключаться в тестировании хорошего репрезентативного диапазона объектов SalesPolicy. Но если вы даете это как часть конструктора или добавляете это позже, это не делает это легче или сложнее.

Если, с другой стороны, SalesEngine не всегда нуждается в SalesPolicy для работы, то вам определенно следует принять предложение Hunter. Это было бы более подходящим интерфейсом и облегчило бы бремя тестирования в случаях, когда не требуется SalesPolicy.