Шаблон проектирования для классов с определенным ограничением

Question

Мне недавно задали этот вопрос в интервью. Мне пришлось разрабатывать классы для игры в крикет, где будет класс для команды, для игрока и так далее. В команде крикета может быть только 11 игроков. Мне пришлось разрабатывать классы, чтобы команда могла иметь ограничение, что она может иметь только определенное количество игроков типа. Например, одно ограничение может заключаться в том, что команда может иметь только 4 бэтсмена, 5 боулеров и 2 раунда. Или у команды может быть ограничение, что у нее могут быть 3 бэтсмена, 6 боулеров и 2 раунда.

Так какой особый шаблон дизайна для такого сценария?

Answer 1

Нет.

Подведение итогов (из комментариев ниже) вы можете разместить до 11 игроков. Это ограничение.

Я бы решить легко, получая количество двух видов игроков в качестве аргументов в конструкторе --- например Team::Team(int batsmen, int bowlers) --- и вычисление другого номера как разница:

class Team { 

public: 

Team::Team (int batsmen, int bowlers){ 
    if (batsmen + bowlers > 14) 
     throw std::runtime_error ("Too many players"); 
    int rounders = 14 - batsmen - bowlers;   
    // Allocate players 
} 

private: 
    std::vector<Batsman> bat_; 
    std::vector<Bowler> bows_; 
    std::vector<Rounder> rounds_; 
}; 

Answer 2

Это не так много о конкретном шаблоне проектирования.

Я думаю, что точка такого вопроса (особенно в интервью) заключается в том, что вы создаете различные варианты дизайна. Например, давайте начнем с

class AbstractPlayer 
{ /* stuff */ }; 

class Batsman : public AbstractPlayer 
{ /* stuff */ }; 

class Bowler : public AbstractPlayer 
{ /* stuff */ }; 

class AllRounder : public AbstractPlayer 
{ /* stuff */ }; 

Тогда вы могли бы пойти на

class Team 
{ 
public: 
    void addPlayer(Batsman player); 
    void addPlayer(Bowler player); 
    void addPlayer(AllRounder player); 

    /* stuff */ 
}; 

В качестве альтернативы он может быть

class Team 
{ 
public: 
    void addBatsman(AbstractPlayer player); 
    void addBowler(AbstractPlayer player); 
    void addAllRounder(AbstractPlayer player); 

    /* stuff */ 
}; 

Во всяком случае, вы должны решить, будет ли вы

1. магазин тех, игроков в одном списке AbstractPlayer s и подсчитать число различных типов игроков в различных целочисленных свойств или
2. магазин игроков в трех различных списках динамической длины

До сих пор так хорошо, предположим теперь, как-то у вас есть несколько типов игроков в класс Team. Где ограничения? Они могут быть установлены как три максимальных отсчетов в конструктору

Team::Team(int maxBatsmanCount, int maxBowlerCount, int maxAllRounderCount) { ... } 

или там может быть какая-то присваивателя (если для одного Team экземпляра номера могут меняться)

Team::adjustConstraints(int maxBatsmanCount, int maxBowlerCount, int maxAllRounderCount) { ... } 

Есть еще больше способов Я могу думать. Как насчет класса ограничений? Но это зависит от требований к классу Team.

Answer 3

Чтобы на самом деле сказать что-либо значимое в этом вопросе, мне понадобится гораздо больше информации, об игре и о будущем.

Я могу только догадываться, куда был направлен вопрос. В какой-то момент они, вероятно, спросят: «Что, если ограничение заключалось в том, что бэтсмен не должен весить более 80 кг?)

-то вдоль линий:

void Main() 
{ 
    Console.WriteLine("Current team valid: " + 
     new Team(
      new List<Player>{ 
       new Batsmen(), 
       new Batsmen(), 
       new Batsmen(), 
       new Batsmen() 
      }).IsTeamValid()); 
} 

abstract class Player {} 
class Batsmen : Player{} 

class Team { 
    static readonly IList<TeamConstraint> DefaultConstraints 
     = new List<TeamConstraint>{new BatsmenConstraint()}; 

    IList<TeamConstraint> _constraints; 
    IList<Player> _players; 

    public Team(IList<Player> players) : this(players, DefaultConstraints){} 
    public Team(IList<Player> players, IList<TeamConstraint> constraints){ 
     _constraints = constraints; 
     _players = players; 
    } 

    public bool IsTeamValid(){ 
     return _constraints.All(constraint => constraint.IsValid(_players)); 
    } 
} 

abstract class TeamConstraint 
{ 
    public abstract bool IsValid(IList<Player> players); 
} 

class BatsmenConstraint : TeamConstraint 
{ 
    const int batsmenRequiredDefault = 4; 
    readonly int _batsmenRequired; 

    public BatsmenConstraint(int batsmenRequired = batsmenRequiredDefault){ 
     _batsmenRequired = batsmenRequired; 
    } 

    public override bool IsValid(IList<Player> players){ 
     return players.OfType<Batsmen>().Count() == _batsmenRequired; 
    } 
} 

Как вы можете видеть, ограничения отдельно от класса команды. Таким образом, вы будете следовать принципам SOLID.

Вы можете:

1) добавить новые конфигурации команды динамически

2) создают новые ограничения динамически без изменения существующей системы.

Что касается вашего вопроса; нет «шаблона дизайна крикетной игры». Вы можете использовать несколько разных шаблонов при попытке решить эту проблему, одна из них подходит лучше, чем другие, и т. Д.

Что я в основном сделал здесь, так это то, что я использовал «bridge pattern» для того, чтобы

Разделить абстракцию от ее реализации, чтобы два могут независимо друг от друга.

, говоря о взаимоотношениях между командой & TeamConstraint.

Answer 4

Вы можете использовать простой Specification схему:

class MyTeamPlayersSpecification { 

    bool isSatisfiedBy(Team team) { 
    // return team.batsmenCount == 4 && ... 
    } 
} 

ли спецификация проверяется один раз при построении команды или в методе Validate() каждый раз, когда вы добавляете игрок зависит от контекста проблемы и ваших личных предпочтений ,

Answer 5

class TeamFactory 
{ 
    static const int bowler; 
    static const int batsman; 
    static const int allrounder; 
    static const int totalPlayer; 

    static Team* getTeam(int _bowler, int _batsman, int _allrounder) 
    { 
     if (((_bowler + _batsman + _allrounder) > totalPlayer) || (allrounder condition) || (_batsman condition) || _allrounder condition) 
     { 
      // error msg 
      getTeam(_bowler, _batsman, _allrounder) 
     } 
     else 
     { 
      // create instance, 
     } 
    } 

}