2012-03-11 3 views
4

У меня есть класс, в котором я хочу расширить функциональность в стиле декоратора/адаптера, но я не хочу, чтобы мой расширяющийся класс знал что-либо о типах классов, которые он расширяет , и я не хочу писать новый класс для каждого типа объекта, который я хочу расширить. Однако все объекты, которые я хотел бы расширить, имеют общий базовый класс, Team. Это звучит созрело для использования дженерик, так что здесь была моя первой мысль:Какой дизайн шаблона это будет, и это хорошая идея? (C#)

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; } 
    } 
} 

Это сделало бы то, что я хотел, как сейчас, если я хочу, чтобы получить доступ к членам Т, новый класс имеет все из них. Базовый конструктор позаботится о настройке состояния таким образом, чтобы расширенный класс не нуждался в этом. Мне также не нужно было бы знать, какие методы следует переопределять, чтобы указать на внутренний объект в стиле декоратора/фасада. Излишне говорить, что это не скомпилировалось. Итак, я попробовал что-то совсем другое.

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; } 
     } 
    } 

ОК, теперь, если я хочу получить на функциональности «базового класса», я просто называю собственностью команды, и я хорошо идти. И, поскольку он является общим, мне не нужно делать какой-либо бокс, чтобы добраться до функциональности. он работает, он довольно красивый, но он работает.

Какой шаблон это, если он существует, и какие подводные камни видят с этой идеей? Есть ли лучший способ сделать это?

ответ

1

это то, что должно быть сделано, как я вижу это «благосклонность состава над наследованием» основным и «стратегия» модель (если им не ошибается)

Я также, как в implimentation.

1

Очень жаль, что C# не позволяет наследовать от параметров типа, потому что я думаю, что первый дизайн идеален, учитывая то, что вы хотите достичь.

Второй дизайн кажется разумным применением шаблона адаптера, при условии, что вы гарантируете, что все члены TournamentTeam, унаследованные от Команды, будут перенаправлены на инкапсулированные команды.

Лично, если бы я должен был спроектировать это в C#, я бы канаву шаблон адаптера в пользу простой композиции и сделать что-то вроде следующего:

  • Rename TournamentTeam к чему-то еще ... может быть TournamentTeamAllocation или TournamentTeamInfo или что-то в этом роде (имена сложны!). В принципе, это было бы отвечает за работу с данными, относящимися как к турниру и команда (то есть семена)
  • Изменить его так, чтобы он ничего
  • не подкласс Держите герметизацию так, что он все еще содержит T : Team.
Смежные вопросы