GOF patterns used

• Singleton Design Pattern: The GameRules should be created only once during the whole gameplay and even across all players. As GameRules is independent of any state.
• Memento + Prototype Design Pattern: The Undo functionality needs to store the snapshot of the current state of all the general components(Board). So, used the Memento design pattern for saving the current Board state. Also, used a Prototype pattern to create a clone of the current board state.
• Template Method: The Game Rules class has a lot of logic regarding game play. So if there is more than one variant of a chess game (Crazy House chess, Chess960, and etc.) then there can be a lot of redundant code for move validation, as the flow of checking validation remains the same for each game type so to avoid that we have used the Template method design patten here.
• Bridge Design pattern: we have used the Bridge pattern to decouple the Board abstraction from the Game Rule Implementation. This way we can have multiple variants of a game played on a single board otherwise Board would get a lot bulkier with code for each type of variant.

Grasp Patterns used

• Creator: The creation of objects is one of the most common activities in an object-oriented system. For us, the Constructor of Board Game in itself consists of creating multiple objects. 2 major objects that it creates are 1) GameComponent 2) GameRules. For the creation of the Game Component, we require to create Board and other items as per the selected Game. Board is represented by the Matrix of squares. and a square contains an Arraylist of pieces. Now, once the game components are created we get an instance of GameRules. As the GameRules remain the same across all the same games that the user plays, it does not require us to create multiple objects/instances of GameRules so to avoid that we use a singleton pattern in its creation.

• Controller: A controller object is a non-user interface object responsible for receiving or handling a system event. Here, we have used multiple controllers at multiple levels, like the main BoardGame class is itself a controller it will delegate all the tasks to the specific objects. GameComponent class will be the controller as it delegates the updation of Board, Timer, and other Game components as per the game to respective objects.

• High Cohesion: We have kept all the classes as simple as possible and assigned only one responsibility to them. The Player class will have all the information related to the player, and it will be solely responsible for manipulating them. Then, we have Pieces, Timer, Board, and GameRules. All of these classes are focused on making them easy to manage and understand. This makes the classes Cohesive.

• Polymorphism: The TicTacToeBoardGame, ChessBoardGame, and all other classes will be extended from the BoardGame class. Depending upon the game selected, the GameComponent class will extend the game-specific class like TicTacToeGameComponent, ChessGameComponent, which returns the necessary components required to play the game. We have polymorphism at multiple levels currently. For example, GameRules is extended to ChessGameRules, and TicTacToeGameRules, etc. Also, we have used the Bridge design pattern for the decoupling of the abstraction (BoardGame) from the implementation (ChessGameRules, Chess960GameRules, CrazyHouseGameRules). This makes the code easy to reuse, debug and maintain.

• Low Coupling: Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. Like, GameRules will only focus on the task of saving the game state and would not interact with other classes for its task. Similarly all the other classes that we have created like Pieces, ChessTimer, etc will all perform their specific tasks. Also we have created a separate GameComponent to lower the coupling for our main class (BoardGame). This makes the code easy to reuse,debug and maintain.

• Pure Fabrication: A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion. The GameComponent Class is used to create all the components required for Board Game, avoiding BoardGame to interact with other classes, reducing the coupling and increasing the cohesion.

• Indirection: The ChessBoardGame, GameComponent classes will mediate between other components (GameRules, Pieces, Board, etc) so that they are not directly coupled.

• Protected Variations: The TicTacToe, Chess class, Chess960, CrazyHouseChess and the BoardGame Class will not impact each other even if they get changes.

UC1: Initiate the game

UC2: Play the game

UC3: Validate the move

UC4: Check End Game

UC5: Undo Move