Design Payment TerminalmediumDesign Payment Terminal
A payment terminal relies on two collaborators: a gateway that decides whether a charge is approved and an auditor that records what happened. The legacy implementation represents both as strings and branches on them inside the terminal. Worse, selecting an auditor resets the gateway, so two unrelated configuration choices are accidentally coupled.
Refactor the starter code while preserving the public PaymentTerminal API:
PaymentTerminal()creates a terminal using theinstantgateway and thesilentauditor.boolean useGateway(String kind)switches to"instant"or"strict"and returnstrue. Anything else changes nothing and returnsfalse.boolean useAuditor(String kind)switches to"silent"or"verbose"and returnstrue. Anything else changes nothing and returnsfalse.boolean charge(double amount)asks the gateway whether the amount is approved, tells the auditor what happened, and returns the gateway's answer.int approvedCount()returns how many charges were approved.int auditCount()returns how many audit lines were recorded.String[] auditLog()returns the recorded audit lines, in order.
The collaborators behave as follows:
- The
instantgateway approves every amount. Thestrictgateway approves amounts up to500and refuses anything above. - The
silentauditor records nothing. Theverboseauditor records"<gateway> <amount> OK"or"<gateway> <amount> DENIED", with the amount to two decimals.
Swapping one collaborator never disturbs the other, so all four combinations work.
PaymentTerminal is the only type the tests instantiate. Give approval and auditing separate, cohesive contracts, then let the terminal coordinate them without containing either collaborator's rules.
Example 1:
Input:
Output:
Explanation: A new terminal approves everything and records nothing, because of the two collaborators it starts with.
Example 2:
Input:
Output:
Explanation: With a strict gateway and a verbose auditor, both outcomes are recorded and only the smaller charge is approved.
Constraints:
0 <= amount <= 10^6kindis 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 gateway and the auditor are held behind separate contracts and the terminal contains neither approval logic nor log formatting. Lose points heavily when charge decides approval by comparing the amount itself, or when it formats an audit line inline.
- Independent substitution
Full marks when either collaborator can be swapped without disturbing the other, so all four combinations behave as expected. Lose points when changing one resets the other, or when the terminal has to know which auditor it holds in order to decide whether to record.
- Structure and naming
Full marks when a no-op auditor needs no special case, an unrecognised kind for either collaborator leaves the current one in place, and the approved count follows the gateway's verdict. Lose points when the ceiling or the log format appears outside the type that owns it, 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 PaymentTerminal() | null |
| charge(900) | true |
| auditCount() | 0 |
| approvedCount() | 1 |
| auditLog() | [] |
A new terminal approves everything and records nothing, because of the two collaborators it starts with.
Run checks these cases. Submit also runs a larger hidden set.