Design and Implement an Object-Oriented Pizza Ordering System

Design and implement an object-oriented simulation of a pizza ordering system. A customer builds an order made of one or more pizzas, and each pizza is defined by a size, a crust type and a set of toppings. The system must price each pizza and the whole order from menu data, and it must track each order's status from the moment it is placed until it is finished. Implement the core classes and operations, then demonstrate a complete order flow: create an order, add pizzas, get a price, place the order, and move it through its statuses. ```hint Keep the menu separate from the order Prices and available options change on a different schedule than orders do. Decide which object should know what a large size or an extra portion of cheese costs, and keep that knowledge out of the pizza and order classes. ``` ```hint Guard the status changes Decide where a rule such as "an order that is already being prepared cannot be edited" is enforced, so that no caller can bypass it by assigning a field directly. ``` ### Constraints and Clarifications - Treat this as a single-process simulation; no database, network API or payment integration is required unless the interviewer extends it. - Money must be computed exactly; state how you represent it. ### Clarifying Questions - How is a pizza priced: a base price by size, plus a crust surcharge, plus per-topping charges? Does a topping cost more on a larger pizza? - Can a customer order the same topping twice (an extra portion), and is there a limit on toppings? - Are there fixed menu pizzas in addition to build-your-own? - Which statuses exist, and until which status can an order be edited or cancelled? - Does the simulation need a kitchen that processes orders (for example a queue with limited ovens), or only the order model? - Are delivery versus pickup, discounts or taxes in scope? ### What a Strong Answer Covers - A class model that separates menu and pricing data, pizzas, orders and order status - Pricing driven by menu data rather than hard-coded branches for each size or topping - An explicit order lifecycle whose legal transitions are enforced in one place - Validation of unknown options, empty orders, invalid topping portions and edits after placement - Extension points for new toppings, sizes and promotions without editing the core classes - A runnable demonstration or tests of a full order flow, including a rejected illegal transition ### Follow-up Questions - Add a kitchen with a limited number of ovens that processes placed orders first in, first out. How do status changes flow from the kitchen back to the order? - Add a deal such as a fixed price for two large pizzas. How does it combine with per-topping charges and other promotions? - Menu prices change while a customer is still editing an order. Which price does the customer pay, and how does your model guarantee it? - Several cashiers place and update orders at the same time. Which parts of your design need synchronization, and how would you provide it?