根据类型添加行为的最佳方式

Question

我有一个公司实体

public class Company : Entity<Company>
{
     public CompanyIdentifier Id { get; private set; }
     public string Name { get; private set; }
     ..............
     ..........
}

公司可以是代理商或供应商，也可以是两者或都不是。 （有更多类型）它的行为应该基于类型而改变。代理可以获得佣金，供应商可以开具发票。 设计实体或实体或值对象的最佳方式是什么？我可以选择添加一些布尔类型并检查方法中的这些值，

 public class Company : Entity<Company>
    {
         public CompanyIdentifier Id { get; private set; }
         public string Name { get; private set; }
         public bool IsAgent { get; private set; }
         public bool IsSupplier { get; private set; }
         ..........

         public void Invoice()
        {
                if(!IsSupplier)
                {
                    throw exception.....;
                }
                //do something
        }

        public void GetCommission(int month)
        {
                if(!IsAgent)
                {
                    throw exception.....;
                }
                //do something
        }
         ..........
    }

说实话，我不喜欢这样。是否有任何设计模式可能有助于克服这种情况？你会做什么以及为什么要设计这个场景？

Answer 1

显式实现接口，然后覆盖强制转换运算符以仅在有效时强制转换为该接口。

public class Company : ...., IAgentCompany, ISupplierCompany ... {

    public double IAgentCompany.GetCommission(int month) {
            /*do stuff */
    }

    public static explicit operator IAgentCompany(Company c)  {
        if(!c.IsAgent)
            throw new InvalidOperationException();
        return this;
    }
}

接口的显式实现必须通过接口调用，而不是具体类型：

// Will not compile
new Company().GetCommission(5);

// Will compile
((IAgentCompany)new Company()).GetCommission(5)

但是，现在我们已经重载了显式转换运算符。那是什么意思？我们不能在不强制转换为 IAgentCompany 的情况下调用 GetCommission，现在我们有一个守卫来防止对未标记为代理的公司进行强制转换。

这种方法的好处：

1) 您拥有定义不同类型公司的各个方面以及它们可以做什么的接口。接口隔离是个好东西，可以明确各类公司的能力/职责。

2) 您已经取消了对您要调用的每个函数的检查，这些函数不是对所有公司都“全局”的。您在转换时进行一次检查，然后只要将它放在一个类型为接口的变量中，您就可以愉快地与它进行交互而无需任何进一步的检查。这意味着引入错误的地方更少，无用的检查也更少。

3) 您正在利用语言特性，并利用类型系统来帮助使代码更加安全。

4) 您不必在代码中随处使用 NotImplementedExceptions 或 InvalidOperationException 编写大量实现各种接口组合的子类（可能是 2^n 个子类！）。

5) 您不必使用枚举或“类型”字段，尤其是当您要求混合和匹配这些能力集时（您不仅需要枚举，还需要标志枚举）。使用类型系统来表示不同的类型和行为，而不是枚举。

6) 它是干的。

这种方法的坏处：

1) 显式接口实现和覆盖显式强制转换运算符并不完全是 C# 编码知识，可能会让你之后的人感到困惑。

编辑：

好吧，我没有测试这个想法就回答得太快了，这对接口不起作用。但是，请参阅我的其他答案以了解其他想法。

Answer 2

我会考虑将所有这些类型的实现分离到不同的类中。您可以通过使用枚举来表示公司类型来开始执行此操作。

public enum CompanyType
{
  Agent = 0,
  Supplier
}

public abstract class Company : Entity<Company>
{
   public CompanyIdentifier Id { get; private set; }
   public string Name { get; private set; }
   public CompanyType EntityType { get; private set; }

   public abstract void Invoice();
   public abstract void GetCommission(int month);
   ...

这样可以减少公共属性。

接下来，我将为供应商和代理实现专门的类（然后两者都没有）。您可以将 Company 抽象化，也可以将任何专门的方法抽象化。

这将允许您区分每种实体的不同行为。当您返回它进行维护时会派上用场。它还使代码更易于阅读/理解。

public class SupplierCompany : Company
{
   public SupplierCompany()
   {
     EntityType = CompanyType.Supplier;
   }

   public override void Invoice()
   {...}
   public override void GetComission(int month)
   {...}
}

public class AgentCompany : Company
{
   public AgentCompany()
   {
     EntityType = EntityType.Agent;
   }

   public override void Invoice()
   {...}
   public override void GetComission(int month)
   {...}
}

有了这个，您可以消除在 Invoice 和 GetComission 等方法中对各种类型的测试。

Answer 3

与大多数DDD 问题一样，它通常归结为Bounded Contexts。我猜您在这里处理的是一些不同的有界上下文（这从您的陈述中最为明显“公司可以是代理或供应商，或两者兼而有之，或都不是。”）。在至少一种情况下，您需要平等地考虑所有Company 实体，无论它们是代理还是供应商。但是我认为您需要考虑您的Invoice 或GetCommission 操作是否适用于更广泛的背景？我想说这些将适用于更专业的环境，其中Agent 和Supplier 之间的区别更为重要。

您可能会遇到麻烦，因为您正在尝试创建一个适用于 所有 上下文的包罗万象的 Company 实体...如果没有奇怪的代码结构，这几乎是不可能实现的 &与类型系统作斗争（正如您在其他答案中所建议的那样）。

请阅读http://martinfowler.com/bliki/BoundedContext.html

大致了解您的上下文的外观：

Broad "Company" Context
{
    Entity Company
    {
        ID : CompanyIdentifier
        Name : String
    }
}

Specialized "Procurement" Context
{
    Entity Supplier
    {
        ID : CompanyIdentifier
        Name : String
        Invoice()
    }
}

Specialized "Sales" Context
{
    Entity Agent
    {
        ID : CompanyIdentifier
        Name : String
        GetComission()
    }
}

尝试在采购和销售上下文中使用相同的对象是否有意义？毕竟，这些上下文有非常不同的要求。 DDD 的一个教训是，我们将领域划分为这些有界上下文，不要试图制造无所不能的“上帝”对象。