这会是什么样的设计模式，这是一个好主意吗？ （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成员都将其调用重定向到封装的团队。

就个人而言，如果我在C＃中设计它，我会抛弃适配器模式，转而使用普通合成，并执行以下操作：

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