Классы без логики: запах кода или уродливый системный факт?

Я работаю над приложением, которое частично вычисляет суммы налоговых платежей. Налоговый счет состоит из множества вычисляемых полей (гонорары шерифа, гонорары клерка, штрафы, проценты, фиксированные ставки и т. д.), способ расчета которых обычно статичен, но может меняться в соответствии с законодательством или специальным счетом. характеристики. Целые категории расчетов также могут быть удалены или добавлены с течением времени.

Чтобы убрать от клиента беспорядок логики ветвления, я написал фабрику для каждой категории вычислений, которая будет применять правильные вычисления с учетом информации о счете, например так (CalcType — это перечисление):

var bill = new Bill(){year = 2013};
bill.AdvertisingFee = CalculationFactory.GetFee(CalcType.AdvFee, bill);

Это очень просто, но меня беспокоит то, как будут реализованы некоторые из моих конкретных классов. Вот интерфейс расчета:

public interface ITaxCalculation{
    decimal Calculate();
}

Типичная реализация будет иметь какие-то вычисления или доступ к данным, но определенные свойства year/bill не приносят платы за рекламу, например:

public class FinanceCabinetAdvertisingFee : ITaxCalculation
{
    public decimal Calculate()
    {
        return 0.00M;
    }
}

Этот класс-заглушка будет присутствовать для многих, но не для всех категорий расчетов по разным причинам (расчет не существовал для налогового года, государство купило счет и т. д.).

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