Design Order ProcessormediumDesign Order Processor
An online shop processes physical goods, digital products, and gift boxes. Customers should experience one consistent checkout flow, even though each order type calculates totals, takes payment, and handles delivery differently.
The shop already has a working OrderDesk. Your job is to implement only the classes that model the Template Method pattern:
OrderProcessor, the abstract base class that defines the checkout workflow.PhysicalOrderProcessor,DigitalOrderProcessor, andGiftBoxOrderProcessor, which supply the order-specific behavior.
Do not reimplement OrderDesk; it is included in the starter code and connects your processors to the tests. The tests use its public API:
OrderDesk()creates a desk that has processed nothing.String[] process(String kind, int amount)runs a"physical","digital"or"giftbox"order for that item subtotal and returns the steps it carried out, in order. An unrecognised kind returns["UNKNOWN"], and an amount of0or less returns["INVALID"]. Neither counts as processed.boolean shipsPhysically(String kind)returns whether that kind runs the shipping step. An unrecognised kind returnsfalse.int totalFor(String kind, int amount)returns the order total before any discount, or0for an unrecognised kind or a non-positive amount. It does not count as processed.int processedCount()returns how many orders have been processed.
Every order runs these steps in this order: validate, state the total, apply a discount, take payment, arrange shipping if the order needs it, and send the confirmation.
- Validation always produces
"Validating order items". - The confirmation always produces
"Sending the confirmation email". - The total step produces
"Total: $<total> <note>". A physical order adds6to the subtotal with the noteincluding $6 shipping, a digital order adds nothing with the notewith no shipping, and a giftbox order adds12with the noteincluding $12 gift wrapping and delivery. - The discount step produces
"No discount applied"unless the order type replaces it. A physical order produces"Applying 10% discount, paying $<final>"when the total is above100, where<final>is the total minus one tenth of it rounded down, and"Order under $100, no discount"otherwise. - Payment produces
"Charging the credit card","Charging the digital wallet"or"Charging the gift card". - Shipping runs for physical and giftbox orders only, producing
"Scheduling courier pickup"and"Scheduling a signed-for delivery". A digital order has no shipping entry in its transcript.
Keep the workflow in one template method on OrderProcessor. Shipping must be an optional hook: a digital order should omit the step entirely, without returning an empty string and without making the base class check the order type.
Example 1:
Input:
Output:
Explanation: A physical order adds $6 shipping to the $120 subtotal, and $126 is above $100, so the discount step reports the reduced amount. Shipping runs because the physical order opted into it.
Example 2:
Input:
Output:
Explanation: A digital order carries no shipping entry at all rather than an empty one, and it inherits the default discount line. totalFor reports the same $120 the transcript states.
Constraints
-50 <= amount <= 1000kindis a lower-case word of at most20letters.- At most
100calls in total are made across all methods.
How the design is graded
needs 7/10 to pass- The skeleton lives in the base class
Full marks when the workflow order is written once in a base-class method that subclasses cannot replace, and each order type supplies only its own total, payment and shipping lines. Lose points heavily when each order type repeats the sequence, or when the base class branches on the order kind.
- Optional steps are hooks
Full marks when both the shipping step and the discount step are decided by overridable methods carrying base-class defaults, so a digital order contains no shipping code at all. Lose points heavily when the skeleton tests for a physical order before shipping, or when the shipping line is always appended and left empty for digital orders.
- Structure and naming
Full marks when `totalFor` reuses the calculation the transcript reports, an unrecognised kind returns `["UNKNOWN"]` and a non-positive amount returns `["INVALID"]` without counting, and the ten percent discount rounds down. Lose points 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 OrderDesk() | null |
| process("physical", 120) | ["Validating order items","Total: $126 including $6 shipping","Applying 10% discount, paying $114","Charging the credit card","Scheduling courier pickup","Sending the confirmation email"] |
| processedCount() | 1 |
A physical order adds $6 shipping to the $120 subtotal, and $126 is above $100, so the discount step reports the reduced amount. Shipping runs because the physical order opted into it.
Run checks these cases. Submit also runs a larger hidden set.