"上帝类"反模式与继承深度控制

为图省事，把某个子类才需要的功能直接塞进公共基类，短期看起来省了重复代码，但随项目推进，基类会不断堆积各种”少数子类才用得上”的能力，逐渐膨胀成一个看似什么都能干、实则谁都不敢轻易改动的”上帝类”——改一处可能牵连所有子类，新增需求又忍不住继续往里塞。另一个连带问题是继承链太深：为省事直接继承一个外观相似的已有类、重写几个方法，一旦原类需求发生大改，继承链上的每一层都要跟着排查。应对方式是把只属于少数子类的功能改用组合/封装实现而不是塞进基类，并把继承层级控制在较少的层数以内，尽量用继承的”宽度”（多个平级的具体子类）替代继承的”深度”。