Animal基类不该带具体实现，应将make_sound()、move()等声明为抽象方法以强制子类覆盖，避免默认行为导致测试失败；“既是鸟又会游泳”应通过组合+接口实现，而非多重继承。
Animal 基类该不该带具体实现？
不该。把 make_sound()、move() 这类行为声明为抽象方法，比塞个 pass 或空字符串返回更安全。Python 用 abc.ABC 和 @abstractmethod，Java 用 abstract 关键字——目的不是炫技，是堵住“忘了重写”的漏洞。常见错误是基类里写了 print("animal moves")，结果新增的 Penguin 类继承后跑出来“animal moves”，而不是“waddles”。这会让测试用例在后期突然失败，而且很难定位。
实操建议：
- 基类只定义接口契约，不提供默认行为（除非业务上真有通用逻辑，比如所有动物都有
age属性） - 子类必须覆盖所有
@abstractmethod，否则实例化时直接报TypeError: Can't instantiate abstract class ... - 避免在基类构造函数里调用可被重写的实例方法，容易触发子类未初始化就执行的 bug
怎么处理“既是鸟又会游泳”的交叉行为？
别用多重继承模拟“身份”，用组合 + 接口。比如 Penguin 不该同时继承 Bird 和 Swimmer，而应实现 Swimmable 接口，并持有 wing 和 flipper 等行为组件。Python 里用协议（Protocol）或抽象基类；Java 用 interface。常见错误是写 class Penguin(Bird, Swimmer)，结果 __init__ 调用链混乱，或者 super().__init__() 不知道该调谁的。
实操建议：
- 用接口（
Swimmable、Flyable）描述能力，而非用继承描述“是什么” - 如果某动物需要动态切换行为（比如受伤后暂时不能飞），就把行为抽成独立类，通过
self.flight_behavior = NoFly()赋值替换 - 警惕 Python 的 MRO（方法解析顺序），
Penguin.mro()要能一眼看懂调用路径
Zoo 类该不该管动物生命周期？
该管，但只管“引用”和“调度”，不管“创建细节”。Zoo 应持有 list[Animal]，提供 add_animal()、remove_animal()、daily_routine()，但绝不出现 if type == "lion": return Lion(...)。这种硬编码会让加新动物时必须改 Zoo，违背开闭原则。常见错误是把动物工厂逻辑塞进 Zoo.__init__()，导致单元测试无法注入 mock 动物。
实操建议：
-
Zoo构造函数接收已创建好的动物实例，不负责 new - 工厂逻辑单独拎成
AnimalFactory类或函数，比如create_animal("penguin", age=2) -
Zoo.daily_routine()内部遍历调用每个动物的eat()、make_sound()，不区分类型——多态在这里真正起作用
Python 里用 dataclass 还是普通 class 定义 Animal？
优先 dataclass，但得关掉自动生成 __init__ 以外的魔术方法。比如 @dataclass(eq=False, unsafe_hash=False) 是常见起点。因为动物对象要比较是否同一实体（id 或 name），不是字段全等；也不该被意外放进 set 或当 dict key。常见错误是直接写 @dataclass，结果 Lion("leo") == Lion("leo") 返回 True，但实际是两只不同狮子。
实操建议：
- 用
@dataclass(slots=True)节省内存，尤其动物数量大时 - 把行为方法（
make_sound()）写在dataclass外部，保持数据与逻辑分离 - 如果需要验证字段（比如
age > 0），用__post_init__，别依赖field(default_factory=...)做校验
真正难的不是画出类图，是每次加一个新动物、改一条规则时，你能不能三秒内判断该动哪几个类、会不会影响已有测试。边界往往藏在“看起来没影响”的地方，比如给 Animal 加个新字段，dataclass 默认让它参与 __eq__，而你忘了同步更新所有 assert。
