如何处理臃肿胖接口？遵循ISP、SRP原则的接口重构方案

你拆分胖接口为IDimensions、IMovement、IColour等细粒度接口的思路符合接口隔离原则，但实现类依然臃肿的根源是：你把不同职责的业务逻辑全部耦合在Shape实体类内部，违背了单一职责原则——图形实体类的核心职责是维护自身的核心状态，不应该承载尺寸计算、运动控制、渲染着色这些跨领域的行为逻辑。

不要让图形类直接实现所有细粒度接口并编写全量逻辑，而是将不同维度的逻辑抽离为独立的协作组件，图形类仅持有核心状态、通过组合方式调用组件完成对应操作，具体落地分三步：

1. 抽离职责维度的独立实现，不把逻辑塞在图形类中 #

你之前拆分的细粒度接口可以保留，但接口的具体实现要和图形实体类完全解耦：

• 尺寸计算逻辑抽为独立的计算器族：通用计算逻辑放在基类计算器中，不同图形的特殊计算规则（比如圆的面积、三角形周长）拆为对应策略实现
• 移动与动画逻辑抽为独立的控制器族：专门处理坐标变更、动画帧计算、运动轨迹生成等逻辑
• 着色相关逻辑抽为独立的渲染器族：专门处理填充色、描边、渐变、纹理填充等渲染相关逻辑

2. 图形核心类仅保留最小状态，通过组合持有对应组件 #

图形类本身只维护自身的核心属性，所有跨职责的操作全部委派给持有的组件执行，参考实现如下：

// 图形抽象基类，仅维护所有图形共有的核心标识、基础坐标状态
public abstract class Shape {
    protected String id;
    protected double x;
    protected double y;

    // 组合持有各职责组件，而非自己实现所有逻辑
    protected IDimensionCalculator dimensionCalculator;
    protected IMovementController movementController;
    protected IColourRenderer colourRenderer;

    // 构造方法注入对应组件实现
    public Shape(IDimensionCalculator dimensionCalc, IMovementController movementCtrl, IColourRenderer colourRender) {
        this.dimensionCalculator = dimensionCalc;
        this.movementController = movementCtrl;
        this.colourRenderer = colourRender;
    }

    // 方法仅做委派，不写具体逻辑
    public double calculateArea() {
        return dimensionCalculator.calculateArea(this);
    }

    public void move(double deltaX, double deltaY) {
        movementController.move(this, deltaX, deltaY);
    }

    public void fill(String colourHex) {
        colourRenderer.fill(this, colourHex);
    }

    // 核心属性get/set省略
}

// 圆形类仅维护自身特有属性（半径），不需要写冗余业务逻辑
public class Circle extends Shape {
    private double radius;

    public Circle(double radius, IDimensionCalculator dimensionCalc, IMovementController movementCtrl, IColourRenderer colourRender) {
        super(dimensionCalc, movementCtrl, colourRender);
        this.radius = radius;
    }

    public double getRadius() {
        return radius;
    }
}

3. 各职责逻辑独立迭代，完全不侵入图形核心类 #

后续扩展逻辑时不需要修改任何图形类代码：

• 新增尺寸计算规则（比如计算外接矩形、计算对角线长度），只需要扩展计算器类即可
• 新增动画效果（比如弹性移动、渐入渐出），只需要新增对应运动控制器实现，注入给需要的图形对象即可
• 新增着色能力（比如透明度调整、图案填充），只需要扩展渲染器实现即可

• 彻底解决实现类臃肿问题：Circle、Square、Triangle等图形类的代码量可以压缩到几十行，仅维护自身特有属性和简单的委派逻辑，所有复杂业务逻辑全部下沉到独立的职责类中
• 复用性极强：通用逻辑不需要在每个图形类中重复编写，比如所有图形的平移动画完全可以共用同一个运动控制器实现
• 可测试性更高：每个职责组件可以独立编写单元测试，替换实现时不需要修改图形类代码，比如要给三角形换一套特殊的面积计算规则，只需要注入专属的计算器实现即可
• 完全符合开闭原则：新增能力时只需要加新的组件和接口，不需要修改现有图形类的代码

注意：如果单个图形存在专属特殊行为（比如直角三角形独有的边长校验逻辑），可以在对应图形类中保留少量专属逻辑，或注入专属的策略实现即可，不会造成代码冗余。

内容的提问来源于stack exchange，提问作者Daniel Viaño