# Compare Functional and Object-Oriented Python Design Compare functional and object-oriented approaches for a Python component that transforms records while maintaining configuration and optional cached state. Explain encapsulation, immutability, pure functions, dependency injection, composition, testing, and how Python code can technically bypass naming conventions or access internal attributes. ### Constraints & Assumptions - Python's leading underscore is a convention, not an access-control boundary. - Double-underscore names are mangled but can still be reached deliberately. - The design should make side effects and mutable state visible. - Do not equate functional programming with banning every object or OOP with requiring inheritance. ### Clarifying Questions to Ask - Is state shared across calls, and does it need synchronization? - Are transformations naturally composable and deterministic? - Does the component need multiple interchangeable implementations? ```hint Separate core and shell Keep deterministic record transformation pure while a thin object owns configuration, cache, and I/O. ``` ```hint Do not promise privacy Name mangling prevents accidental collisions; it is not a security feature. ``` ### What a Strong Answer Covers - Trade-offs grounded in the component's state, behavior, and extension points. - Python-specific encapsulation limits and why social and API boundaries still matter. - A composition-oriented design that can combine pure transformations with a state-owning object. - Testing, concurrency, serialization, and evolution implications. ### Follow-up Questions - When would a closure be clearer than a class instance with one method? - How would frozen data classes change the trade-off?