这是哪种设计模式？它是否是一个好主意？（C#）

Question

我有一个类，想以装饰器/适配器的方式扩展其功能，但我不希望扩展类知道它正在扩展哪种类型的类，也不想为每种要扩展的对象编写新类。然而，我想要扩展的所有对象都共享一个基类Team。这听起来很适合使用泛型，所以这是我的初始想法：

public class TournamentTeam<T> : T
   where T : Team
{
   private int mSeed;

   public TournamentTeam(T team, int seed)
      : base(team)
   {
      /*
       * error checking stuff here
       */

      // set class variables
      this.mSeed = seed;
   }

   public int Seed
   {
      get { return this.mSeed; }
   }
}

如果这样做，我想我的需求就可以得到满足，因为现在如果我想访问T的成员，新类已经拥有了它们。基础构造函数会设置状态，使扩展类不必担心它。我也不需要知道要覆盖哪些方法以便以装饰器/门面类型的方式指向内部对象。不用说，这无法编译。所以，我尝试了一些不同的方法。

    public class TournamentTeam<T> : Team
        where T : Team
    {
        #region class variables
        private int mSeed;
        private T mTeam;
        #endregion

        public TournamentTeam(int seed, T team)
            : base(team)
        {
            /*
             * error checking stuff here
             */

            // set class variables
            this.mSeed = seed;
            this.mTeam = team;
        }

        public int Seed
        {
            get { return this.mSeed; }
        }

        public T Team
        {
            get { return this.mTeam; }
        }
    }

好的，现在如果我想要使用“基类”的功能，我只需要调用Team属性就可以了。而且，由于它是泛型的，我不需要进行任何装箱操作即可获得功能。虽然有点丑陋，但它确实有效。

如果存在模式，这是什么模式，你们看到了哪些缺陷？有更好的方法来实现这个吗？

- aaronburro

Answer 1

据我看来，应该遵循“优先使用组合而非继承”的原则和“策略”模式（如果我没记错的话）。

我也喜欢这种实现方式。

- Nahum

Answer 2

很遗憾，C#不允许从类型参数继承，因为我认为第一种设计是理想的，考虑到你想要实现的目标。

第二种设计似乎是适配器模式的一个合理应用，只要确保所有从Team继承的公共TournamentTeam成员将其调用重定向到封装的Team即可。

就我个人而言，如果我要在C#中设计这个，我会放弃适配器模式，转而采用简单的组合，并执行以下操作：

• 将TournamentTeam重命名为其他名称...也许是TournamentTeamAllocation或TournamentTeamInfo之类的名称（名称很难取！）。基本上，它将负责处理与锦标赛和团队（即种子）相关的数据
• 更改它，使其不再是任何东西的子类
• 保持封装性，以便仍包含T：Team。

- asdfjklqwer