Overview
TheTask class represents a kitchen preparation task assigned to a specific station. When an Order is received, it’s broken down into multiple Tasks—one for each station that needs to prepare products. Tasks track their lifecycle from creation through completion with status transitions and timestamps.
Tasks are the unit of work in the kitchen system. Each Task is assigned to exactly one Station and tracks its own preparation lifecycle.
Class Definition
Fields
Immutable Fields
Unique identifier for the task. Set to
null on creation and assigned by persistence.Reference to the parent Order that generated this task. Cannot be null.
The kitchen station responsible for this task (BAR, HOT_KITCHEN, or COLD_KITCHEN).
The table number from the original order. Used for task identification.
Products assigned to this task (filtered by station). Must contain at least one product.
Timestamp when the task was created. Cannot be null.
Mutable Fields
Current status of the task. Initialized to
PENDING and transitions through IN_PREPARATION to COMPLETED.Timestamp when the task was started. Set when
start() is called.Timestamp when the task was completed. Set when
complete() is called.Constructors
Public Constructor
orderId- Parent order ID (required)station- Assigned station (required)tableNumber- Table number (required, cannot be empty)products- Products to prepare (required, cannot be empty)createdAt- Creation timestamp (required)
status=TaskStatus.PENDINGstartedAt=nullcompletedAt=null
Reconstruction Factory Method
Validation Rules
The Task class enforces strict validation rules:| Field | Validation | Exception |
|---|---|---|
| Order ID | Cannot be null | IllegalArgumentException |
| Station | Cannot be null | IllegalArgumentException |
| Table Number | Cannot be null or empty (after trim) | IllegalArgumentException |
| Products | Cannot be null or empty | IllegalArgumentException |
| Created At | Cannot be null | IllegalArgumentException |
| ID (reconstruct) | Cannot be null when reconstructing | IllegalArgumentException |
State Transitions
Tasks follow a strict state machine with validation:start()
- Task status must be
PENDING
- Sets
statustoTaskStatus.IN_PREPARATION - Sets
startedAtto current timestamp
IllegalStateExceptionif task is not in PENDING status
complete()
- Task status must be
IN_PREPARATION
- Sets
statustoTaskStatus.COMPLETED - Sets
completedAtto current timestamp
IllegalStateExceptionif task is not in IN_PREPARATION status
Public Methods
Getters
getProducts() returns a defensive copy to prevent external modifications to the task’s product list.Usage Example
Business Logic
Task Creation from Orders
Tasks are typically created by grouping Order products by their station:Time Tracking
Tasks automatically track three important timestamps:- createdAt - When the task was created (set on construction)
- startedAt - When kitchen staff began preparation (set on
start()) - completedAt - When preparation finished (set on
complete())
Design Patterns
State Machine Pattern
Tasks enforce valid state transitions through methods that check preconditions and throw exceptions on invalid transitions.
Factory Method Pattern
The
reconstruct() method provides a controlled way to rebuild tasks from persistence with all their state.Defensive Copying
The products list is defensively copied in both constructor and getter to maintain immutability.
Related Models
- Order - Parent order that generated this task
- Product - Products to be prepared in this task
- Station - Kitchen station assigned to this task
- TaskStatus - Status enum for task lifecycle