本文介绍在 java 抽象基类的 static main 方法中，不依赖硬编码、不修改子类的前提下，自动发现并实例化所有继承自该基类的具体子类，从而实现“一次编写、多子类复用”的命令行工具模式。
在面向对象设计中，将通用入口（如 main 方法）放在抽象基类中是一种简洁的架构思路——它避免了为每个子类重复编写启动逻辑。但问题在于：抽象类无法直接实例化，而 main 是静态方法，不能直接访问 this 或子类类型。因此，关键挑战是如何在运行时动态识别并创建当前被 JVM 启动的子类实例。
遗憾的是，Java 标准库不提供“获取当前正在执行的类是否为某抽象类子类”的反射能力。例如，当执行 java MOne 5 时，JVM 加载的是 MOne 类，但 Calculation.main() 并不知道自己是被 MOne 调用的（因为 main 是静态的，且 MOne 并未重写它）。因此，不能简单通过 getClass() 获取调用者。
一种可行但不推荐的方案是：强制要求每个子类重写 main 并委托给基类（如 Calculation.run(new MOne(), args)），但这违背了“统一入口”的初衷，也丧失了封装性。
更优雅且生产可用的方案是：利用类路径扫描 + 当前执行类推断。核心思想是——虽然 Calculation.main() 不知道谁调用了它，但我们可以从 JVM 的启动参数和调用栈中反向推导：
✅ 推荐做法（简洁、可靠、无需第三方库）：
让 main 方法读取 JVM 启动时的 sun.java.command 系统属性（JDK 内置，非标准但广泛支持），从中提取主类名，再通过反射实例化：
public abstract class Calculation {
public abstract int multiply(int x);
public static void main(String[] args) {
// 获取 JVM 启动命令（如 "MOne 5"）
String cmd = System.getProperty("sun.java.command");
if (cmd == null || args.length == 0) {
System.err.println("Usage: java ");
return;
}
// 提取主类全限定名（取第一个空格前的部分）
String mainClassName = cmd.split("\\s+")[0].trim();
try {
// 加载并实例化该子类（需无参构造函数）
Class clazz = Class.forName(mainClassName);
if (!Calculation.class.isAssignableFrom(clazz) || clazz == Calculation.class) {
throw new IllegalArgumentException(mainClassName + " is not a valid Calculation subclass");
}
Calculation instance = (Calculation) clazz.getDeclaredConstructor().newInstance();
// 解析参数并调用 multiply
int x = Integer.parseInt(args[0]);
System.out.println(instance.multiply(x));
} catch (Exception e) {
System.err.println("Error: " + e.getMessage());
e.printStackTrace(System.err);
}
}
} ✅ 此方案优势：零依赖、轻量、精准——它总是实例化真正被 java 命令启动的那个类，完全匹配 java MOne 5 → MOne 实例 → multiply(5) 的语义。
⚠️ 注意事项：
- 子类必须提供public 无参构造函数（默认即满足）；
- sun.java.command 在部分安全策略严格环境（如某些容器或 JDK 模块化限制下）可能不可用，此时可降级使用 Thread.currentThread().getStackTrace() 解析调用栈（但需谨慎处理索引）；
- 该方案不适用于 java -cp ... Calculation 启动方式（因此时主类是 Calculation，而它是抽象类），应始终用 java Subclass ... 方式调用。
❌ 不推荐原始答案中的“扫描所有子类”方案：
它会加载并实例化 所有 继承自 Calculation 的类（如 MTwo, MThree），但用户只期望运行 MOne。这不仅浪费资源、引发意外副作用（如构造函数含 I/O），更违背单一职责——main 应驱动当前命令，而非批量执行全部实现。
总结：面向可扩展 CLI 工具的设计，应优先利用 JVM 启动上下文（sun.java.command）实现精准动态绑定，而非盲目扫描。这既保持了抽象基类的统一入口价值，又确保了行为的确定性与高效性。
