Bird
Raised Fist0

ESPNcricinfo System - Match, Innings, Ball, Scorecard, Commentary

LLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/4
Match-Innings composition

Match composes multiple Innings instances, showing strong lifecycle ownership where Innings cannot exist without Match.

🎯 Tests understanding of composition in Java where Match holds a List<Innings> and controls Innings lifecycle, enforcing encapsulation and SOLID single responsibility.
public class Match {
    private final List<Innings> inningsList = new ArrayList<>();
    public synchronized void startMatch() {
        inningsList.add(new Innings());
    }
}
Innings as abstract class

Innings is abstract to hold shared state like ballsList and runsScored, which interfaces cannot hold in Java.

🎯 Tests why abstract class is chosen over interface due to instance fields and partial method implementations, enforcing code reuse and state encapsulation.
public abstract class Innings {
    protected List<Ball> ballsList = new ArrayList<>();
    protected int runsScored = 0;
    public void addBall(Ball ball) {
        ballsList.add(ball);
        runsScored += ball.getRuns();
    }
    public int getRuns() { return runsScored; }
}
Ball association with Innings

Ball is associated with Innings but has independent lifecycle; Innings holds ballsList but Ball can exist independently.

🎯 Tests understanding of association vs composition in Java, where Ball is not tightly lifecycle-bound to Innings, allowing reuse or separate creation.
public class Ball {
    private final int ballNumber;
    private final int runs;
    public Ball(int ballNumber, int runs) {
        this.ballNumber = ballNumber;
        this.runs = runs;
    }
    public int getRuns() { return runs; }
}
Scorecard singleton concurrency

Scorecard is a singleton with volatile instance and synchronized getInstance() to ensure thread-safe lazy initialization.

🎯 Tests knowledge of Java concurrency mechanisms: volatile prevents instruction reordering, synchronized ensures atomic check-and-set for singleton instance.
public class Scorecard {
    private static volatile Scorecard instance;
    private Scorecard() {}
    public static synchronized Scorecard getInstance() {
        if (instance == null) {
            instance = new Scorecard();
        }
        return instance;
    }
    public synchronized void updateScore() {
        // update logic
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       |    <<Singleton>>|
       |     Match      |
       +----------------+
       | - inningsList  |
       | - scorecard    |
       +----------------+
       | + startMatch() |
       | + endMatch()   |
       +----------------+
              ◆ composition
              │
       +----------------+
       |   <<Abstract>> |
       |    Innings     |
       +----------------+
       | - ballsList    |
       | - runsScored   |
       +----------------+
       | + addBall(Ball)|
       | + getRuns()    |
       +----------------+
              ◆ composition
              │
       +----------------+
       |     Ball       |
       +----------------+
       | - ballNumber   |
       | - runs         |
       +----------------+
       | + getRuns()    |
       +----------------+
              ─ ─ ─► association
              │
       +----------------+
       |   Scorecard    |
       +----------------+
       | - playerStats  |
       +----------------+
       | + updateScore()|
       +----------------+
Design Rationale

This class diagram illustrates key Java OOP design decisions for the ESPNcricinfo system. Match is a singleton class composing multiple Innings instances, enforcing strong lifecycle ownership and encapsulation. Innings is modeled as an abstract class to hold shared mutable state like ballsList and runsScored, which interfaces cannot hold in Java, enabling code reuse and partial implementation. Ball is associated with Innings but has an independent lifecycle, demonstrating association versus composition. Scorecard is implemented as a thread-safe singleton using volatile and synchronized to prevent concurrency bugs during lazy initialization. These decisions align with SOLID principles, Java concurrency best practices, and lifecycle ownership clarity.

Primary Focus

✓ Composition lifecycle + Abstract class state sharing + Singleton concurrency + Association vs Composition

Practice

(1/5)
1. In designing the Chess game, should the Piece abstraction be an abstract class or an interface, and why?
easy
A. Abstract class, because interfaces cannot enforce method implementation.
B. Interface, because pieces only declare move behavior without shared state.
C. Interface, because Java interfaces can hold state since Java 8.
D. Abstract class, because pieces share common state like position and color.

Solution

  1. Step 1: Analyze shared state among pieces

    All pieces share common state such as position on the board and color, which is best encapsulated in a base class.

  2. Step 2: Evaluate abstract class vs interface

    Abstract classes allow shared state and common method implementations, while interfaces primarily declare behavior without state.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Shared state -> abstract class preferred over interface [check]
Hint: Shared state? Use abstract class, not interface [check]
Common Mistakes:
2. In a traffic light system design, a TrafficLightController class has a private constructor and a static synchronized getInstance() method. Which design pattern is applied here and why is this the correct choice?
easy
A. Factory pattern to create multiple controller instances safely
B. Builder pattern to construct complex traffic light states
C. Prototype pattern to clone traffic light controllers for scalability
D. Singleton pattern to ensure only one controller manages the traffic lights

Solution

  1. Step 1: Identify the pattern from constructor and method

    The private constructor prevents external instantiation, and the static synchronized getInstance() ensures a single shared instance, matching Singleton pattern characteristics.

  2. Step 2: Why Singleton fits traffic light controller

    Only one controller should coordinate the traffic lights to avoid conflicting states; multiple instances would cause inconsistent signals.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Private constructor + synchronized getInstance() -> Singleton pattern [check]
Hint: Private constructor + static synchronized getInstance() -> Singleton [check]
Common Mistakes:
3. In designing the File and Directory classes, should FileSystemEntity be an abstract class or an interface? Why?
easy
A. Interface, because it allows multiple inheritance and only defines behavior without state.
B. Abstract class, because interfaces cannot enforce method implementation.
C. Interface, because Java interfaces can now have default methods with state.
D. Abstract class, because it can hold common state like name and permissions shared by files and directories.

Solution

  1. Step 1: Identify shared state and behavior

    Both File and Directory share common state such as name, permissions, timestamps, so a base class holding this state is needed.

  2. Step 2: Abstract class vs interface for state

    Interfaces cannot hold instance fields; abstract classes can hold state and provide common method implementations, making abstract class the correct choice.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Shared state -> abstract class, not interface [check]
Hint: Shared state? Use abstract class, not interface [check]
Common Mistakes:
4. In designing the Post entity for Facebook, should Post be an abstract class or an interface, considering it has state like content and timestamp, and behavior like edit() and delete()? Why?
easy
A. Abstract class, because it can hold shared state and provide default behavior implementations.
B. Interface, because it allows multiple inheritance and enforces method signatures without state.
C. Interface, because state can be stored externally and behavior defined separately.
D. Abstract class, because interfaces cannot have any methods with implementation.

Solution

  1. Step 1: Analyze state and behavior requirements

    Post has shared state (content, timestamp) and behavior (edit, delete) that benefit from default implementations.

  2. Step 2: Abstract class vs interface capabilities

    Abstract classes can hold state and provide method implementations; interfaces cannot hold state (pre-Java 8) and only declare methods.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    State + behavior with default code -> Abstract class [check]
Hint: Stateful with behavior -> Abstract class, stateless -> Interface [check]
Common Mistakes:
5. In a parking lot system, if parkVehicle() is not synchronized, which exact sequence of Thread 1 and Thread 2 causes double-booking of the same spot?
medium
A. Thread 1 checks isAvailable() -> true, context switch; Thread 2 checks isAvailable() -> true; both park the vehicle in the same spot.
B. Thread 1 and Thread 2 both call parkVehicle() simultaneously and crash.
C. Thread 1 parks vehicle, then Thread 2 parks vehicle after spot is freed.
D. Thread 1 calls parkVehicle(), Thread 2 waits until Thread 1 finishes, then parks.

Solution

  1. Step 1: Identify the check-then-act race condition

    Without synchronization, Thread 1 reads spot as available, then context switches before marking it occupied.

  2. Step 2: Trace Thread 2's actions

    Thread 2 also reads spot as available and proceeds to park, causing double-booking.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Unsynchronized check-then-act -> both threads see available -> double-booking [check]
Hint: Check-then-act gap without sync -> double-booking race [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard