c# - 无逻辑类 : Code Smell or Ugly System Fact?

Question

我开发的应用程序在一定程度上计算税单金额。税单由许多可计算的字段(警长费用、文员费用、罚款、利息、统一税率等)组成，其计算方式通常是静态的，但可能会因立法或特殊法案而改变特性。随着时间的推移，整个类别的计算也可能会被删除或添加。

为了避免客户端出现困惑的分支逻辑，我为每个计算类别编写了一个工厂，它将在给定账单信息的情况下应用正确的计算，就像这样(CalcType 是一个枚举):

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

这很简单，但我对某些具体类的实现方式感到困扰。下面是计算界面:

public interface ITaxCalculation{
    decimal Calculate();
}

典型的实现会有某种计算或数据访问，但某些年份/账单属性不会产生广告费，如下所示:

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

出于各种原因(纳税年度不存在计算、州购买账单等)，许多但不是所有计算类别都会出现这种 stub 类

我的问题:像这样的无逻辑类是否被认为是一种代码味道，或者只是对某些不稳定的真实世界系统建模的丑陋事实？我喜欢将这些案例牢固地记录在一个类中而不是作为某些控制结构的默认返回值的想法，但我对我将错误类型的模式应用于此类问题的想法持开放态度。欢迎任何其他想法。

Answer 1

我会把像这样的魔法值放在数据库或配置文件中，如果你想对用户隐藏它，可能会加密。那么这个类将是一个数据访问类，并且在需要时更新值会更容易和更模块化。

有时需要在代码中硬编码数据，但这可能不是最佳选择。