如何屏蔽客户端访问封装层继承自不可修改外部库的方法

核心原则：只要你用继承，就不可能100%完全阻断客户端对A类方法的访问，所有基于继承的方案都是补丁级防护，按优先级从高到低方案如下：

• 替换继承为组合委托（最推荐，无任何漏洞）
  直接取消B对A的继承关系，在B类内部定义一个private级别的A类型实例成员，所有B需要用到的A的能力，都通过B自定义的公开方法做内部转调，按需对外暴露允许客户端使用的能力。
  这种实现下，A的所有公开方法完全不会出现在B的对外API列表中，客户端拿到B的实例时，根本感知不到A的存在，从根源上避免了方法误用，不存在反射、类型转换之类的绕开路径。
  简单实现示例：

  // 错误实现：继承会直接把A的所有public方法暴露给客户端
  class B extends A {
      // 你的自定义封装逻辑
  }
  
  // 正确实现：组合持有私有A实例，仅开放指定方法
  class B {
      // 私有实例，客户端完全无法访问
      private final A innerA = new A();
  
      // 只对外暴露你允许客户端调用的方法
      public void validMethodForClient() {
          // 这里可以加你自己的封装逻辑、参数校验、埋点之类的
          innerA.doSomething();
      }
  }
  

  这个方案唯一的成本是需要手动写一层委托转调的代码，但是可控性最高，长期维护成本最低。

• 继承场景下的多层防护（仅适合历史包袱太重、暂时改不了继承关系的情况）

  • 覆写所有A类中不对外开放的public方法，方法内部直接抛出UnsupportedOperationException，同时在注释中标明该方法为内部实现细节，禁止客户端调用。注意要同步覆盖A类父级传来的公开方法，避免遗漏。
    示例：

    class B extends A {
        /**
         * 内部方法，禁止客户端调用
         * @throws UnsupportedOperationException 调用即抛出
         */
        @Override
        public void internalMethodFromA() {
            throw new UnsupportedOperationException("该方法为封装层内部实现，不对外开放");
        }
    }
    

    这个方案的缺陷是只能在运行时报错，无法在编译期阻止用户写调用代码，而且每次升级A的版本都要检查有没有新增的公开方法需要屏蔽。
  • 加编译期静态检查规则：用CheckStyle、ArchUnit这类静态扫描工具，在C项目的构建流程中加校验规则，一旦发现代码中直接调用A类的方法、或者调用B中被标记为屏蔽的继承方法，直接构建失败，把问题拦截在编码阶段。
  • 模块化隔离：如果你的技术栈支持模块化能力（比如Java 9+ JPMS、OSGi），可以在模块配置中把A类所在的包设置为不对外导出，C项目作为依赖方根本看不到A类的定义，自然无法直接调用相关方法。

注意：继承关系下的防护永远有被绕开的可能，比如客户端可以通过反射修改访问权限、或者把B实例强制转换为A类型后调用原生方法，只要业务上能改，优先选组合方案。

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