如何扩展基础单例AccessInfo以包含用户角色等信息？

嘿Kyle！看到你想扩展AccessInfo这个基础单例来加入用户角色这类额外信息，刚好我之前做过类似的场景，结合你已经熟悉的Graph、Cache扩展逻辑，给你几个经过实践验证的最优实现路径参考：

1. 继承扩展（最直接的兼容方案） #

如果AccessInfo的设计允许继承，这是最直接的方式——直接创建子类继承它，在子类中补充userRole、department等额外属性就行，完全复用父类的现有逻辑，和你扩展Graph、Cache的思路一致。

需要注意的是要重写单例的获取方法，确保返回的是子类实例，示例代码（以Java为例）：

public class ExtendedAccessInfo extends AccessInfo {
    private String userRole;
    // 按需添加其他用户属性

    private static ExtendedAccessInfo instance;

    private ExtendedAccessInfo() {
        super(); // 调用父类的私有/保护构造
    }

    // 保证线程安全的单例获取方法
    public static ExtendedAccessInfo getInstance() {
        if (instance == null) {
            synchronized (ExtendedAccessInfo.class) {
                if (instance == null) {
                    instance = new ExtendedAccessInfo();
                }
            }
        }
        return instance;
    }

    // 新增属性的getter/setter
    public String getUserRole() {
        return userRole;
    }

    public void setUserRole(String userRole) {
        this.userRole = userRole;
    }
}

这个方案完全符合开闭原则，不需要改动原有AccessInfo的代码，风险最低。

2. 组合模式（适合不可继承的场景） #

如果AccessInfo是框架提供的、构造方法完全私有且没有预留扩展点的类，那组合模式会是更稳妥的选择：创建一个新的单例类，内部持有AccessInfo的实例，同时封装用户角色等额外信息。

示例代码：

public class UserAccessContext {
    private final AccessInfo accessInfo;
    private String userRole;
    private String userDepartment;

    private static UserAccessContext instance;

    private UserAccessContext() {
        this.accessInfo = AccessInfo.getInstance(); // 复用原有单例
    }

    public static UserAccessContext getInstance() {
        if (instance == null) {
            synchronized (UserAccessContext.class) {
                if (instance == null) {
                    instance = new UserAccessContext();
                }
            }
        }
        return instance;
    }

    // 委托原有AccessInfo的方法，对外保持一致的调用体验
    public String getAccessToken() {
        return accessInfo.getAccessToken();
    }

    // 新增属性的访问方法
    public String getUserRole() {
        return userRole;
    }

    public void setUserRole(String userRole) {
        this.userRole = userRole;
    }
}

这种方式完全隔离了扩展逻辑，不会对原有单例产生任何影响，适合原有代码无法修改的场景。

3. 装饰器模式（动态扩展场景） #

如果你需要动态给AccessInfo添加不同的用户属性（比如不同业务场景下需要不同的信息维度），装饰器模式会是最灵活的选择——和你扩展Graph时的动态插件思路异曲同工。

首先定义一个和AccessInfo接口一致的装饰器类，内部持有原实例并添加额外属性：

public class AccessInfoDecorator implements AccessInfo {
    private final AccessInfo delegate;
    private String userRole;

    public AccessInfoDecorator(AccessInfo delegate) {
        this.delegate = delegate;
    }

    // 实现AccessInfo的所有接口方法，委托给原实例
    @Override
    public String getAccessToken() {
        return delegate.getAccessToken();
    }

    // 新增属性的访问方法
    public String getUserRole() {
        return userRole;
    }

    public void setUserRole(String userRole) {
        this.userRole = userRole;
    }
}

使用时可以动态包装原单例：

AccessInfo original = AccessInfo.getInstance();
AccessInfoDecorator decoratedInfo = new AccessInfoDecorator(original);
decoratedInfo.setUserRole("ADMIN");

这个方案的优势是可以叠加多个装饰器，动态组合不同的用户属性，灵活性拉满。

关键注意事项 #

• 无论用哪种方案，都要保证单例的线程安全性，双重检查锁（DCL）是常用的安全实现方式；
• 如果需要和Cache集成，可以在扩展后的类中直接复用你熟悉的Cache逻辑，比如将用户角色信息缓存起来避免重复获取；
• 如果AccessInfo是框架类，优先查看官方文档是否有预留的扩展点（比如可注入的属性、回调接口），用官方方式扩展最稳妥。

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