继承场景下将Function<T,R>用作Supplier<R>，如何表明无需用泛型参数并传null？

针对继承导致的Function<T, R>占位需求，以下是几种务实的传达方案，按约束强度从弱到强排序：

1. 显式文档说明（最直接的告知方式） #

在叶子类的类注释、构造方法注释以及Function字段注释中，明确标注参数的用途：

/**
 * 此类继承自XX父类，持有的Function仅作为Supplier<R>使用，会**完全忽略传入的参数**
 * <p>初始化时请传入{@code null}，该参数不会被业务逻辑调用
 */
public class LeafClass<T, R> extends ParentClass<T, R> {
    /**
     * @param func 仅用于满足父类继承要求，不会被使用，请传入{@code null}
     */
    public LeafClass(Function<T, R> func) {
        super(func);
        // 后续逻辑仅将func当作Supplier使用，不调用apply(T)
    }
}

• 优点：实现成本最低，所有查看类定义的开发者能直接获取信息
• 缺点：依赖开发者主动阅读文档，无法强制避免错误传参

2. 提供专用的无参构造/工厂方法（引导正确使用） #

如果父类允许子类构造时自行处理参数，可封装无需传参的创建方式，同时废弃原构造方法：

public class LeafClass<T, R> extends ParentClass<T, R> {
    /**
     * @deprecated 请使用{@link #create()}方法创建实例，此参数无需使用
     */
    @Deprecated(since = "1.0", forRemoval = false)
    public LeafClass(Function<T, R> func) {
        super(func);
    }

    /**
     * 创建LeafClass实例，内部自动传入占位用的null
     */
    public static <R> LeafClass<?, R> create() {
        return new LeafClass<>(null);
    }
}

• 优点：从API层面引导开发者走正确路径，减少错误传参的可能
• 缺点：若父类强制要求必须传入Function实例，此方案需确保null是合法的入参

3. 定义占位用的Function常量（避免NullPointerException） #

如果担心null引发NPE，可以定义一个明确的占位实现，替代null传入：

public class LeafClass<T, R> extends ParentClass<T, R> {
    /**
     * 仅用于占位的Function实现，**禁止调用其apply方法**
     */
    public static final Function<?, ?> PLACEHOLDER_FUNC = t -> {
        throw new UnsupportedOperationException("此Function仅为满足继承要求，不应被调用");
    };

    public LeafClass() {
        super((Function<T, R>) PLACEHOLDER_FUNC);
    }
}

• 优点：避免null潜在的空指针风险，通过异常明确阻止误调用
• 缺点：需要维护额外的常量，且需确保业务逻辑永远不会触发该Function的apply方法

4. 泛型通配符弱化类型约束（暗示参数无关） #

将叶子类的泛型参数T改为通配符，从类型层面暗示该参数无需关注：

/**
 * T类型参数仅用于满足继承要求，无实际业务用途，请传入null或占位实现
 */
public class LeafClass<R> extends ParentClass<?, R> {
    public LeafClass(Function<?, R> func) {
        super(func);
    }
}

• 优点：通过泛型语法直观传递“T类型无关紧要”的信息
• 缺点：仍需配合文档说明，无法完全约束传参行为

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