何时暴露Java对象至包外属不良规范？棋牌项目封装决策指南

一、何时跨包暴露对象属于不良规范 #

• 当对象包含未封装的内部实现细节（比如你的Board类里的Piece二维数组），外部代码可直接修改这些细节，破坏逻辑一致性与封装性
• 暴露的对象没有稳定的公共API，后续修改内部结构时会导致所有依赖它的外部代码崩溃
• 外部代码可通过暴露的对象绕过业务规则（比如直接修改棋盘棋子位置，不走游戏逻辑里的合法移动校验）
• 对象的生命周期应由所属包完全控制，暴露后外部可能不当持有引用，引发内存泄漏或状态混乱

二、针对你的CLI国际象棋项目的建议 #

你当前面临的核心矛盾是「封装游戏逻辑」与「视图层获取棋盘数据」的平衡，直接传递Board对象确实会破坏封装，但传递字符串又不利于后续GUI扩展。更合理的方案是抽象出只读的棋盘数据访问接口：

1. 在GameLogic包下定义公共接口，只暴露视图层需要的方法：

// GameLogic包下的公共接口
public interface BoardView {
    Piece getPieceAt(int row, int col);
    int getRowCount();
    int getColumnCount();
    // 仅包含渲染所需的只读方法，不暴露内部存储结构
}

2. 让Board类实现这个接口，同时保持Board类的其他内部方法（如修改棋子位置）为包私有或受保护：

// GameLogic包下的Board类
class Board implements BoardView {
    private Piece[][] grid;

    @Override
    public Piece getPieceAt(int row, int col) {
        // 边界校验逻辑
        return grid[row][col];
    }

    @Override
    public int getRowCount() {
        return grid.length;
    }

    @Override
    public int getColumnCount() {
        return grid[0].length;
    }

    // 内部修改方法，仅包内可见
    void setPieceAt(int row, int col, Piece piece) {
        grid[row][col] = piece;
    }
}

3. 视图层（ConsoleVisual或后续GUI）仅依赖BoardView接口，而不是具体的Board类：

// 包外的ConsoleVisual类
public class ConsoleVisual {
    public void render(BoardView boardView) {
        StringBuilder sb = new StringBuilder();
        for (int row = 0; row < boardView.getRowCount(); row++) {
            for (int col = 0; col < boardView.getColumnCount(); col++) {
                Piece piece = boardView.getPieceAt(row, col);
                // 渲染逻辑
            }
        }
        System.out.println(sb);
    }
}

这种方式既满足了视图层的数据需求，又完全封装了GameLogic的内部实现，后续即使把Board的二维数组换成其他存储结构（比如Map），只要实现BoardView接口，视图层代码无需修改。

三、是否暴露封装对象的决策流程 #

1. 明确外部需求：先搞清楚外部代码需要对象做什么？是只读访问，还是需要修改状态？如果只是读取，只暴露只读接口
2. 评估风险：暴露对象后，外部会不会破坏内部状态？会不会导致后续修改困难？比如直接暴露Board，外部可能跳过合法移动校验修改棋子，这就破坏了游戏规则
3. 设计最小API：不要暴露整个对象，只提供外部真正需要的方法，避免过度暴露
4. 考虑扩展性：接口要兼容未来的需求变化（比如从CLI到GUI），抽象接口比具体实现更灵活
5. 验证封装边界：确保核心业务规则（如移动合法性、胜负判断）只能通过逻辑包的公共方法触发，外部无法绕过

内容的提问来源于stack exchange，提问作者Tyler