Bird
Raised Fist0

Jigsaw Puzzle System

LLDhardInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/4
PuzzlePiece abstract class

PuzzlePiece is an abstract class holding state like id and edges, which interfaces cannot hold in Java.

🎯 Tests whether candidate understands abstract class is needed to hold shared state and behavior, unlike interfaces which cannot have instance fields.
public abstract class PuzzlePiece {
    private int id;
    private Edge[] edges;
    public int getId() { return id; }
    public abstract boolean fitsWith(PuzzlePiece other);
}
PuzzleBoard composition

PuzzleBoard composes multiple PuzzlePieces, owning their lifecycle, shown by composition symbol ◆.

🎯 Tests if candidate can distinguish composition (PuzzleBoard owns PuzzlePieces lifecycle) from association or aggregation.
public class PuzzleBoard {
    private List<PuzzlePiece> pieces = new ArrayList<>();
    public synchronized void addPiece(PuzzlePiece p) {
        pieces.add(p);
    }
    public boolean isComplete() {
        // check if puzzle is complete
    }
}
FitChecker interface realization

FitChecker is an interface defining canFit method, implemented by concrete classes to check piece compatibility.

🎯 Tests understanding of Strategy pattern where FitChecker interface enables different fitting algorithms without modifying PuzzleBoard or PuzzlePiece.
public interface FitChecker {
    boolean canFit(PuzzlePiece p1, PuzzlePiece p2);
}
BacktrackingSolver realization of PuzzleSolver

BacktrackingSolver implements PuzzleSolver interface and uses FitChecker to solve the puzzle using Template Method pattern.

🎯 Tests if candidate knows Template Method pattern in solve method and why solve is synchronized to prevent concurrent modification of PuzzleBoard.
public class BacktrackingSolver implements PuzzleSolver {
    private FitChecker fitChecker;
    public synchronized boolean solve(PuzzleBoard board) {
        // backtracking algorithm using fitChecker
    }
}
📐
Class Diagram
Class Diagram
       +----------------------+
       | <<Abstract>>         |
       | PuzzlePiece          |
       +----------------------+
       | - id: int            |
       | - edges: Edge[]      |
       +----------------------+
       | + getId(): int       |
       | + fitsWith(Piece):bool|
       +----------------------+
              │ extends
       +----------------------+
       | PuzzleBoard          |
       +----------------------+
       | - pieces: List<PzPiece> |
       +----------------------+
       | + addPiece(PzPiece):void [sync] |
       | + isComplete(): boolean             |
       +----------------------+
              ◆ composition
       +----------------------+
       | <<Interface>>        |
       | FitChecker           |
       +----------------------+
       | + canFit(PuzzlePiece, PuzzlePiece): boolean |
       +----------------------+
              ─ ─ ─► realization
       +----------------------+
       | <<Interface>>        |
       | PuzzleSolver         |
       +----------------------+
       | + solve(PuzzleBoard): boolean |
       +----------------------+
              ─ ─ ─► realization
       +----------------------+
       | BacktrackingSolver   |
       +----------------------+
       | - fitChecker: FitChecker |
       +----------------------+
       | + solve(PuzzleBoard): boolean [sync] |
       +----------------------+
Design Rationale

This class diagram illustrates key Java OOP design decisions in a Jigsaw Puzzle System. PuzzlePiece is an abstract class because it holds instance state like id and edges, which interfaces cannot hold in Java. PuzzleBoard composes PuzzlePieces, owning their lifecycle, enforcing strong containment and lifecycle management. FitChecker is an interface representing the Strategy pattern, allowing different fitting algorithms to be plugged in without modifying existing classes, adhering to the Open-Closed Principle. BacktrackingSolver realizes PuzzleSolver interface and uses FitChecker to implement the Template Method pattern for solving puzzles. The solve method is synchronized to ensure thread-safe puzzle solving, preventing concurrent state corruption. These decisions demonstrate careful use of Java-specific constructs like abstract classes for state, interfaces for behavior, composition for lifecycle ownership, and synchronized methods for concurrency control.

Primary Focus

✓ Abstract class state vs interface behavior + Composition lifecycle + Strategy pattern realization + Template Method in Solver

Practice

(1/5)
1. In the Movie Ticket Booking System, the SeatManager class has a private constructor and a static synchronized getInstance() method. Which design pattern is applied here and why is it the correct choice?
easy
A. Prototype pattern, to clone seat states efficiently.
B. Factory pattern, because it controls object creation centrally.
C. Builder pattern, to construct complex seat objects step-by-step.
D. Singleton pattern, to ensure only one instance manages seat states globally.

Solution

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

    A private constructor prevents external instantiation, and a static synchronized getInstance() method ensures controlled single instance creation.

  2. Step 2: Reason why Singleton fits seat management

    SeatManager must coordinate seat availability globally to avoid conflicting bookings, so a single shared instance is necessary.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Private constructor + static synchronized getInstance() -> Singleton pattern [check]
Hint: Private constructor + static getInstance() = Singleton [check]
Common Mistakes:
2. 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:
3. In a system using the Prototype pattern, should the Vehicle base type be an abstract class or an interface? Why?
easy
A. Abstract class, because it can hold common state and provide default cloning behavior
B. Interface, because it allows multiple inheritance and enforces method signatures without state
C. Interface, because cloning requires no shared implementation or state
D. Abstract class, because interfaces cannot declare clone() methods

Solution

  1. Step 1: Consider cloning and shared state

    Cloning often requires copying internal state; an abstract class can hold this state and provide a default clone() implementation.

  2. Step 2: Evaluate interface limitations

    Interfaces define behavior but cannot hold state or provide default cloning logic (in Java before default methods). Thus, abstract class fits better.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Abstract class holds state + cloning logic -> correct OOP design [check]
Hint: Clone needs shared state -> abstract class better than interface [check]
Common Mistakes:
4. You want to add a WeekendFeeStrategy to calculate parking fees differently on weekends. Given the current design uses a FeeStrategy interface, what is the minimum change to comply with SOLID principles?
medium
A. Modify the existing FeeStrategy implementation to add weekend logic with an if-else block.
B. Merge all fee strategies into a single class with multiple methods for each pricing rule.
C. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed without modifying existing classes.
D. Add a boolean flag isWeekend to the ParkingLot class and change fee calculation accordingly.

Solution

  1. Step 1: Identify SOLID principle

    Open-Closed Principle (OCP) requires classes to be open for extension but closed for modification.

  2. Step 2: Apply OCP

    Creating a new WeekendFeeStrategy class extends functionality without modifying existing code, adhering to OCP and Dependency Inversion Principle.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New strategy class -> extend without modifying existing -> OCP [check]
Hint: Add new strategy class, don't modify existing code [check]
Common Mistakes:
5. The Meeting Scheduler needs to support ElectricCar attendees who require ChargingSpots. What is the minimum change to the current Java design to add this feature without modifying existing classes?
hard
A. Modify Attendee class to include a boolean isElectric flag and add charging logic inside existing RoomBookingManager.
B. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.
C. Create a new ElectricCarAttendee class extending Attendee and add charging spot logic inside it, modifying existing booking classes.
D. Add charging spot support by modifying RoomBookingManager to check for electric vehicles explicitly.

Solution

  1. Step 1: Identify extensibility without modifying existing classes

    Adding new enum values and subclass ElectricCar extends Vehicle allows extension without changing existing class code.

  2. Step 2: Update compatibility map externally

    Updating SpotCompatibility.COMPATIBILITY_MAP to include new mappings supports new vehicle and spot types without class changes.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Extend enums + subclass + update map -> no existing class modified [check]
Hint: Extend enums + subclass + map update -> no class changes [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