Simplify a Login GuardmediumSimplify a Login Guard
Design and refactor a LoginGuard that tracks consecutive failed login attempts.
Its behavior is small:
- it starts with
0failures and is unlocked; recordFailure()increments the count up to a maximum of3, returning"TRY_AGAIN"after the first two failures and"LOCKED"from the third failure onward;recordSuccess()resets an unlocked guard to0and returnstrue;- a success cannot unlock an already locked guard, so it changes nothing and returns
false; failureCount()returns the current count; andisLocked()returns whether the count has reached3.
The legacy starter models four named states and defines every transition with branching logic. Those states are simply the four possible counter values. The extra representation has already produced a bug: success after two failures moves back only one state instead of resetting the guard.
Replace the state machine with the smallest state that expresses the rules.
Example 1:
Input:
Output:
Explanation: The third consecutive failure reaches the cap and locks the guard.
Example 2:
Input:
Output:
Explanation: A success before lockout resets the count in one step. The next failure starts again from one.
Constraints
- At most
100calls will be made across all methods.
Starter Code
The starter compiles and mostly works, but the enum duplicates a counter and makes a simple reset easy to implement incorrectly.
How the design is graded
needs 7/10 to pass- Minimal state representation
Full marks when one bounded integer stores consecutive failures and the locked condition is derived from it. Lose points heavily for retaining the enum, transition table, duplicated flags or separate state objects.
- Simple transitions
Full marks when failure increments up to three, unlocked success resets directly to zero and locked success changes nothing. Lose points for switch-based transition machinery or inconsistent reset paths.
- Exact observable behavior
Full marks when methods return the required statuses and values, repeated locked failures remain at three, and no output is printed. Lose points for counts above three or for unlocking on success.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new LoginGuard() | null |
| failureCount() | 0 |
| isLocked() | false |
| recordFailure() | "TRY_AGAIN" |
| recordFailure() | "TRY_AGAIN" |
| recordFailure() | "LOCKED" |
| failureCount() | 3 |
| isLocked() | true |
Three consecutive failures lock the guard, and the count is capped at three.
Run checks these cases. Submit also runs a larger hidden set.