不知何故，我有一些要求來使用預先撰寫的默認方法的所有好處并apply(T t)從 Java 更改抽象方法（）Function<T, R>。
如果我選擇制作新的@FunctionalInterfaceextends Function<T, R>，方法名稱將是operate(T t)，我想我的代碼將如下所示，
@FucntionalInterface
public interface CustomOperator<T, R> extends Function<T, R>{
R operate(T t);
@override
default R apply(T t){
//do something
}
}
假設所有CustomeOperator僅使用 call的客戶端代碼operate(T t)，如果我希望介面具有默認方法已經提供的所有相同好處，那么填充“ ”部分Function<T ,R>的最佳方法是什么？//do something
我想知道繼承是否不是滿足我要求的最聰明（或可能）的方式。
uj5u.com熱心網友回復：
填充//do something空間的代碼相當簡單：你委托給你的抽象方法：
@Override
default R apply(T t) {
return this.operate(t);
}
丑陋的部分是您需要注意的所有內容以及您需要記住的所有內容（所有這些都是因為Function您的客戶仍然可以看到 的合同）：
子介面和實作類
CustomOperator可以覆寫apply，你不能讓它成為最終的。您必須
default從函式中覆寫所有這些方法，例如：@Override default <V> CustomOperator<V, R> compose(Function<? super V, ? extends T> before) { Objects.requireNonNull(before); //validation to replicate return (V v) -> apply(before.apply(v)); //or operate() }而且，您需要這樣做，因為您的呼叫者使用
CustomOperator，例如，這當然不包含在繼承Function.compose的 中。當
java.util.function.Function<T, R>進化（并且應該進化）時，你需要跟上。
上述挑戰更多是針對您的要求的問題。為什么你需要這樣做？這是可能的，但隨之而來的是維護作業。
而且，既然您已經需要覆寫 中的所有default方法Function，這里有一個很好的問題要問：為什么不直接破壞有問題的繼承呢？您可以復制合同，但CustomOperator獨立于Function.
uj5u.com熱心網友回復：
只有一種合理的實作方式：
@Override
default R apply(T t) {
return operate(t);
}
......這樣做是完全正常的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/435908.html