Design Alert RoutereasyDesign Alert Router
An alert router began with a single delivery channel, so branching on a sender name felt harmless. As more channels arrived, the router absorbed every prefix, delivery rule, and edge case. The starter now knows far too much about its collaborators, and its SMS branch even records messages that the sender refuses.
Refactor the starter code while preserving the public AlertRouter API:
AlertRouter()creates a router using theemailsender and no deliveries recorded.boolean useSender(String kind)switches to"email","sms"or"silent"and returnstrue. Anything else changes nothing and returnsfalse.String currentSender()returns the name of the current sender.boolean send(String message)hands the message to the current sender and returns whether it was delivered.int deliveredCount()returns how many deliveries have been recorded.String[] deliveries()returns the recorded deliveries, in order.
The three senders behave differently:
emaildelivers everything and records"[EMAIL] <message>".smsrefuses a message longer than20characters, and records"[SMS] <message>"for the ones it accepts.silentaccepts everything and records nothing.
A refused message is never recorded.
AlertRouter is the only type the tests instantiate, but it should become a small, cohesive coordinator. Each delivery mechanism should implement the same contract and own its own rules, prefix, and recording behavior.
Example 1:
Input:
Output:
Explanation: A new router uses the email sender, which delivers everything and records what it sent.
Example 2:
Input:
Output:
Explanation: The SMS sender refuses anything over its length limit, and a refused message is not recorded.
Constraints:
1 <= message.length <= 60kindis a lowercase word.- At most
100calls will be made across all methods.
How the design is graded
needs 7/10 to pass- Low coupling
Full marks when the router holds a sender behind a shared contract and swapping one replaces that reference, so the router contains no delivery logic. Lose points heavily when send branches on the sender name and formats the output itself, or when the router constructs a specific sender inside send.
- Substitutability
Full marks when a sender that delivers nothing is an ordinary implementation the router treats like any other, needing no special case. Lose points when the silent sender is handled by an if in the router, or when the router cannot work without a real sender.
- Structure and naming
Full marks when a refused message is not recorded, an unrecognised sender name leaves the current one in place, and each sender owns its own prefix and rules. Lose points when a prefix appears outside its sender or for printing to stdout.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new AlertRouter() | null |
| currentSender() | "email" |
| send("disk full") | true |
| deliveredCount() | 1 |
| deliveries() | ["[EMAIL] disk full"] |
A new router uses the email sender, which delivers everything and records what it sent.
Run checks these cases. Submit also runs a larger hidden set.