[16 Jun,2024][L2023B3,B4,B5,B6,B7] LLD 2:Interview Case Study I:Design Snakes&Ladder Game|Aman Keshu

Summary

The video presents a live low-level design (LLD) interview exercise: designing and partially implementing a Snakes and Ladders game. The instructor first reviews several design patterns, then demonstrates a step-by-step approach to requirements, class design, relationships, and code.

Design-pattern review

The instructor briefly revisits patterns from the previous lesson:

• Singleton: Ensures a class has one shared instance, such as a database connection.
• Builder: Constructs an object gradually, avoiding many constructors for different combinations of optional fields.
• Factory: Centralizes object creation instead of scattering new calls and conditional logic throughout the code.
• Abstract Factory: Adds another level of abstraction by providing specialized factories for related object types.
• Strategy: Allows an algorithm or behavior—such as a payment method—to be selected or changed at runtime.
• Decorator: Adds capabilities to an object without changing its underlying class. The instructor illustrates this with pizza toppings that add descriptions and costs.

Snakes and Ladders requirements and rules

The proposed game has these functional requirements:

• The user supplies a board dimension n; the board has n × n cells.
• The board contains n snakes and n ladders, placed randomly.
• A snake connects a higher-numbered cell to a lower-numbered cell. Landing on its head moves a player down to its tail.
• A ladder connects a lower-numbered cell to a higher-numbered cell. Landing on its start moves a player up.
• Multiple players take turns.

The instructor also lists the game rules:

• Cells are numbered consecutively from 1 to n².
• Each player begins at position 0, outside the board.
• Players take turns rolling a six-sided die, producing a value from 1 to 6.
• A roll normally advances the player by the dice value.
• A player wins by reaching the final cell.
• If a move would take a player beyond the final cell, the player stays where they are.
• Landing on a snake or ladder changes the player’s position accordingly.
• Play continues while at least two players remain; winners are recorded in order.

Interview-design methodology

The instructor recommends treating an LLD question as a sequence of stages:

1. Clarify or establish functional requirements. If the interviewer does not provide them, identify the expected behavior and rules.
2. Identify the main entities and responsibilities. Start with the concepts in the problem—such as a board, players, snakes, ladders, dice, and the game itself—and decide what information or behavior belongs to each.
3. Choose the relationships between classes. For example, a snake and a ladder share start and end positions, so those fields can be placed in a common parent type.
4. Draw a class diagram. Show each class’s attributes, methods, inheritance, and associations.
5. Implement code if requested. In a typical 45-minute or one-hour design interview, requirements and class design may take most of the time. A machine-coding round may require a fuller end-to-end implementation.

A class diagram can be developed from the overall game downward—asking what a game needs—or from basic entities upward. The important point is to maintain a clear design flow.

Proposed classes and relationships

• Game

  • Holds the board dimension and dice count.
  • Manages the board, the players still playing, and the list of winners.
  • Runs the turn-by-turn game loop.

• Board

  • Represents the n × n board.
  • Stores board entities by cell number in a map, allowing the game to check whether a cell contains a snake or ladder.
  • Provides operations for checking or adding entities and printing the board.

• BoardEntity

  • A shared abstract type for objects placed on the board.
  • Stores start and end positions and provides a message describing what a player encountered.

• Snake and Ladder

  • Extend BoardEntity.
  • Supply their own encounter messages and represent their respective movement directions.

• Player

  • Stores a username and current position.
  • Starts at position 0.

• DiceService

  • Generates random dice results.
  • For multiple dice, rolls once per die and sums the results.

• EntityFactory

  • Creates a snake or ladder based on the requested entity type, centralizing construction logic.

The class diagram uses composition for tightly dependent relationships, such as a game containing its board and players. It uses aggregation for the dice service, which can exist independently of a particular game. The instructor distinguishes these “has-a” relationships from inheritance, such as a snake being a kind of board entity.

Implementation walkthrough

The coding demonstration proceeds roughly as follows:

• Create the board from the supplied dimension and initialize its cell-to-entity map.
• Generate random positions for snakes and ladders, ensuring that a snake’s end is below its start and a ladder’s end is above its start.
• Use the factory to construct each board entity.
• Create the requested number of dice rolls and sum their values.
• Store active players in a queue so turns proceed in order; store winners separately.
• For each turn:
  1. Remove the current player from the queue.
  2. Roll the dice and calculate the proposed position.
  3. Check whether the destination contains a snake or ladder and adjust the position if needed.
  4. Keep the player in place if the move would exceed the board.
  5. Add a player who reaches the final cell to the winners list; otherwise, return them to the active-player queue.
• Print the board and turn information to make the run easier to follow.

The instructor acknowledges that checking for conflicts between entity positions can add complexity. The demonstration initially focuses on checking whether a placement location is occupied and defers some of the more detailed overlap considerations. The code is presented as a learning example; students are encouraged to implement the problem themselves rather than rely only on the demonstration.

Speakers and sources featured

• Instructor/presenter: Identified as Aman Keshu in the video title; leads the design review and coding exercise.
• Student participants: Several unnamed attendees answer questions and ask about class design, relationships, and implementation details.
• Background music: Briefly audible during the session.