题目重点：用同一结算任务解释对象职责与纯函数变换，讨论副作用、不可变性和混合使用。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 题目未明确语言或编码任务；本文结算价例只作教学，不嵌入未运行代码。
- 比较主要组织方式和副作用管理，不宣称某一语言只支持一种范式或一种范式天生快。
解题路线
- OOP把数据和行为围绕对象职责组织，通过封装与接口让调用者依业务合同操作。不是必须建深继承树，组合/协议也常用；继承与多态单题见q160。
- 函数式风格强调函数组合、显式数据流与减少可变共享状态；纯函数同输入同输出且无可观察副作用。外部时间、数据库读写、日志和随机等都可能破坏纯性，需显式依赖或隔离到边界。
- 同一购物结算可由Cart/PricePolicy对象表达规则，也可由订单快照经过discount/tax/total等函数变换。对象方法也可纯、函数也可偷偷写global，代码用function关键字不等于纯函数。
- 不可变数据降低别名/并发修改风险，但不自动让全部系统线程安全；外部数据库写仍需事务/幂等。不可变更新可能通过结构共享减少复制成本，不能默认每步完整复制或免费复制。
- 可测试性取决依赖合同：纯核可直接用输入输出测，对象可注入时钟/存储/策略并按接口测。过度mock掩盖业务不变量，两种风格都应把定价规则与IO分开。
- 选型围绕业务模型、团队理解与变化点；流程型数据转换可函数组合，长寿命资源/状态机可对象封装。合理混合比背“FP用于数学/OOP用于现实”更能说明工程判断。
手动走一遍
教学未税价100、折扣10%、税5%，明确先折扣再税得到94.5；如果税先按原价算再折扣得到95，规则次序改变结果。纯函数链应显式编码次序，PricePolicy对象也需同一规则合同；范式不替代业务定义。金额生产通常用整数最小货币单位/Decimal，并定义舍入。
规模与取舍
两种范式不决定统一大O；转换次数、数据复制/结构共享、虚拟派发与IO分别核。并发优势需确认不可变范围和外部副作用，不能只由函数写法推出线性扩展。
易错点与追问
容易失分的边界
- function语法等于纯函数。
- OOP必须深继承。
- 不可变自动全系统线程安全。
- 范式选择代替业务规则。
- 两种范式不能混合。
继续深挖
- 如何把时间/随机依赖显式注入？
- 对象方法可以纯吗？
- 结构共享怎样影响复制成本？
- 金额舍入应该在哪个步骤定义？
