Order

Refactoring beyond the algorithmic surface Arjan Egges argues that messy, deeply nested code is rarely an optimization problem. Instead, it serves as a glaring symptom of structural debt. When you find yourself iterating through orders inside a customer loop, you aren't just writing slow code; you're performing a manual database join in memory because your data structures are misaligned. This tutorial demonstrates how to refactor such "symptoms" using Pythonic principles and clean architecture. Prerequisites To follow this guide, you should be comfortable with Python fundamentals, including list comprehensions and dictionaries. Understanding basic Object-Oriented Programming (OOP) concepts like classes and methods is essential for the behavior placement section. Key Libraries and Tools * **Python Standard Library**: No external dependencies are required, as we leverage built-in types like `dict` and `list`. * **Decimal Module**: Highly recommended for financial calculations to avoid floating-point errors. Eliminating implicit joins with dictionaries Scanning every order for every customer creates an $O(n^2)$ complexity nightmare. By grouping data into a dictionary first, you trade memory for a massive speed boost and flatter code. ```python def group_orders_by_customer(orders): orders_by_customer = {} for order in orders: orders_by_customer.setdefault(order.customer_id, []).append(order) return orders_by_customer ``` By calling this function once, you replace a nested `for` loop with a constant-time lookup: `customer_orders = orders_by_customer.get(customer.id, [])`. Placing behavior in the right domain A common mistake is performing low-level calculations, like summing order items, inside a high-level report generator. This logic belongs inside the Order class itself. Moving this behavior simplifies the caller and respects the object's boundaries. ```python @property def total(self): return sum(item.price * item.quantity for item in self.items) ``` Syntax Notes We utilize the `@property` decorator to make the `total` calculation feel like an attribute access rather than a method call. Furthermore, Python's `sum()` function paired with a generator expression provides a cleaner alternative to manual loop accumulators. Tips and Gotchas * **Incremental Growth**: Messy code often starts with just "one more if statement." Review your nesting depth every time you add logic. * **Single Responsibility**: If a function changes for more than one reason (e.g., the discount logic changes *and* the report format changes), it is doing too much. Split it into discrete helpers like `apply_discount` and `build_summary`.