這是什麼設計模式，這是一個好主意嗎？ （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成員，新類有所有的人。基礎構造函數將負責設置狀態，以便擴展類不需要擔心。我也不需要知道爲了指向裝飾器/外觀類型方式中的內部對象而重寫什麼方法。不用說，這沒有編譯。所以，我嘗試了一些與衆不同的東西。好吧，現在如果我想要了解「基類」的功能，我只需要調用團隊屬性，我很高興。而且，由於它是通用的，我不必做任何拳擊來獲得功能。它的作品，它不漂亮，但它的作品。

這是什麼模式，如果存在的話，以及這個想法有什麼隱患嗎？有沒有更好的方法來完成這一點？

Answer 1

這是我看到的本金和「戰略」的格局（如果林不誤）

我也很喜歡它執行力度 「在繼承青睞組成」應該做什麼。

Answer 2

不幸的是，C＃不允許繼承類型參數，因爲我認爲第一個設計是理想的，因爲你想實現。

第二個設計看起來像是適配器模式的合理應用，前提是您確保從Team繼承的所有公共TournamentTeam成員都將其調用重定向到封裝團隊。

就個人而言，如果我在C＃來設計這個，我會溝適配器模式有利於平原組成，並做類似如下：

• 重命名TournamentTeam別的東西......也許TournamentTeamAllocation或TournamentTeamInfo或類似的東西（名字很難！）。基本上，這將會是負責與有關這兩個比賽和球隊數據處理（即種子）
• 更改它，使它不繼承任何
• 保持封裝，使其仍含有T : Team。