这将是什么设计模式，这是一个好主意吗？ （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属性即可。 而且，由于它是通用的，因此我无需进行任何装箱操作即可使用该功能。 它可以工作，还不错，但是可以工作。

如果存在的话，这是什么模式，您会从这个想法中看到什么陷阱？ 有没有更好的方法可以做到这一点？

Answer 1

这是我应该做的，因为我认为它是“优先考虑组成而不是继承”原则和“策略”模式（如果我没记错的话）

我也喜欢这种暗示。

Answer 2

不幸的是，C＃不允许从类型参数继承，因为鉴于您要实现的目标，我认为第一个设计是理想的。

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

就个人而言，如果我要使用C＃进行设计，那么我将放弃适配器模式以支持简单的组合，并执行以下操作：

• 将TournamentTeam重命名为其他名称……可能是TournamentTeamAllocation或TournamentTeamInfo或类似的名称（很难！）。 基本上，它将负责处理与锦标赛和团队有关的数据（即种子）
• 对其进行更改，使其不会继承任何子类
• 保留封装，使其仍然包含T : Team 。