如果你想讓你的接口在返回類型中是通用的,我會建議擴展JoeC的評論。
自Java 8以來,有java.util.function
-package,爲基本轉換提供接口。特別是,界面Function
可以用於適合您的目的。我建議這樣的實現:
// file: Parser.java
import java.util.function.Function;
public abstract class Parser<R> implements Function<String, R> {
@Override
public final R apply(String document) {
return (this.parse(document));
}
abstract public R parse(String document);
}
對於上面的例子中的一個實例是這樣的:
String document = ...;
Parser<Map<K, V>> mapParser = ...; // instantiate a fitting Parser
Map<K, V> result = mapParser.parse(document);
(鑑於K
和V
在這個代碼塊稱爲通用參數)。
你可以進一步指定的接口來獲得較爲簡單的語法:
// file: MapParser.java
import java.util.Map;
public abstract class MapParser<K, V> extends Parser<Map<K, V>> {}
有了這個(空)接口,您可以重新WIRTE上面的代碼爲:如前所述
String document = ...;
MapParser<K, V> mapParser = ...; // instantiate a fitting MapParser
Map<K, V> result = mapParser.parse(document);
通過@matoni,可以編寫接口IParser
和IMapParser
並在其上設置抽象類別Parser
和MapParser
:
個
的接口提供了一種用於自一個class
用戶可以實現多個interface
S比的靈活性,但只有extends
一個其它class
。然而,不利的是,接口IParser
和IMapParser
的開發人員無法強制執行該方法apply(...)
不能被覆蓋。因此,理論上,Parser
的實施者可以不同地實施apply(...)
和parse(...)
,這可能導致意外的行爲。當使用抽象類Parser
和MapParser
時,開發人員確實會強制執行apply(...)
調用parse(...)
並因此具有一致的行爲。
'分析器'也許? –
像'public interface Parser {E parse(String document); }'? –
4castle
@ 4castle我是新來的接口,可以向我解釋它是如何工作的(你在這裏提到的那個) – user3407267