C#类设计，支付规则灵活

Question

我目前正在为一个负责管理版税支付的系统建模。版税可能很简单:

• 支付作者 A 收入的 15%

或者像其中任何一个一样复杂:

• 向作者 B 支付 15% 的收入，最多售出 1000 件，然后支付 12% 的收入
• 每售出 1000 件，还要向作者 B 支付 1.50 美元

或:

• 为前 1,000 美元的收入向作者 C 支付收入的 15%，然后支付收入的 12%

简而言之，付款可以是每次销售的固定金额，也可以是收入的一定百分比。付款条件可能基于销售数量或收入。我试图设计一个类(它与幕后的数据库表密切相关)，它通过指定支付范围和支付值的类型来包含所有这些灵 active 。但是，我担心我可能试图让这门课做太多事情，如果我们将来需要适应其他情况，我可能会把自己逼到墙角。我正在寻求替代设计方法的建议。

public class PaymentRule
{
    // I'm not 100% comfortable with this, as this will
    // really be an Int32 value for quantity sold ranges
    public decimal RangeMinimum { get; set; }
    public decimal? RangeMaximum { get; set; }

    // This will always be a decimal value, but may represent
    // a dollar amount or percentage depending on the context
    public decimal PaymentValue { get; set; }

    // Specify a type for the range: QuantitySold or Revenue
    public string RangeType { get; set; }

    // Specify a type for the value: AmountPerEachSold or RevenuePercentage
    public decimal ValueType { get; set; }

    public decimal CalculateRoyaltyDue(int quantitySold, decimal revenue)
    {
        // ...
    }
}

如有任何建议，我们将不胜感激。

2012 年 5 月 9 日更新:

我应该提一下，这些规则必须保存到 SQL Server 数据库中。

Answer 1

查看 specification pattern - 这 jar 复杂的规则规范正是它旨在帮助解决的问题。

In computer programming, the specification pattern is a particular software design pattern, whereby business rules can be recombined by chaining the business rules together using boolean logic.

A specification pattern outlines a business rule that is combinable with other business rules. In this pattern, a unit of business logic inherits its functionality from the abstract aggregate Composite Specification class. The Composite Specification class has one function called IsSatisfiedBy that returns a boolean value. After instantiation, the specification is "chained" with other specifications, making new specifications easily maintainable, yet highly customizable business logic. Furthermore upon instantiation the business logic may, through method invocation or inversion of control, have its state altered in order to become a delegate of other classes such as a persistence repository.