所以我正在學習為軟體設計的介紹類構建決議器。
我已經構建了一個 tokenizer 包，它將我的輸入字串拆分為具有值和型別的 getter 的 Token 物件。我還可以為當前令牌的值和型別回傳一個原始字串。
我的 Tokenizer 面向公眾的界面目前看起來像這樣。
public Tokenizer(Grammar rules, String input)
public Token getCurrentToken() {...} // Token has public getters similar to the two methods below
public String getCurrentValue() {...}
public String getCurrentType() {...}
public void nextToken() throws InvalidTokenException {...}
public void previousToken() {...}
在我的 Parser 類中，我還有一個 TokenReceiver(interface) 和一個 TokenizerAdapter 類（實作 Receiver 和我的特定標記器）
public void next();
public Token getToken();
public String getType();
public String getValue();
public Token getToken();
}
規則是決議中的每個不同步驟都必須使用不同的包來完成，這些包與其他包的任何實作細節盡可能松散耦合，即決議器理論上應該與我找到的任何標記器一起作業（例如在 Github 上），而不僅僅是我自己的 Tokenizer 實作，前提是我只是為它制作了一個配接器。
如果我從 Tokenizer 發回 Token 物件，那么我的決議器將不得不知道 Token 物件（特別是 getter 方法），這會增加對我的 Tokenizer 實作的耦合。
回傳值和型別的直接字串，然后在 Parser 包中創建另一個 Token 類并重新創建 Tokens 物件對我來說是本能的錯誤。配接器類中 Token 的匿名內部類是否是一個好的解決方案？
我正在尋找什么樣的模式或概念可以幫助我從 Tokenizer 參考我的 Tokens，同時保持與我的特定 tokenizer 實作的松散耦合。
對不起，如果問題真的很愚蠢并且答案真的很明顯，設計模式對我來說仍然非常抽象，我們正在學習其中的很多，我很難知道在不同的情況下使用哪個。
uj5u.com熱心網友回復：
您是否考慮過以下問題
public interface Tokenizer {
// either
Iterable<Token> parse(String input);
// or
Stream<Token> parse(String input);
}
public class GrammarTokenizer implements Tokenizer {
private final Grammar grammar;
// constructor
// method implementations
}
uj5u.com熱心網友回復：
當您想在類之間傳遞一些物件同時又試圖避免類之間的緊密耦合時，實作介面可能會有所幫助。在您的情況下，可能會創建一個令牌介面并從您的標記器和決議器參考該介面，而不是直接參考具體的令牌類（令牌類應實作令牌介面）。
我會對此發表評論，但我沒有足夠的聲譽來這樣做。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/334810.html