這個(gè)想法是幾周前在設(shè)計(jì)“ Generator”類時(shí)想到的，該類必須將輸入發(fā)送給封裝的Writer 。 實(shí)際上，它是Builder模式。 但是，規(guī)則有些復(fù)雜，用戶必須以某種方式調(diào)用add...()方法，才能正確生成輸出。

不用說，我不喜歡讓一個(gè)BuilderImpl類在內(nèi)部設(shè)置和驗(yàn)證各種標(biāo)志，以便知道什么時(shí)候被允許的選擇。 解決方案是構(gòu)建一個(gè)有限狀態(tài)機(jī) ，因?yàn)闃?gòu)建者的界面很流暢。 像往常一樣，在這篇文章中，我將通過一個(gè)例子來說明。

湯姆和杰瑞（Tom＆Jerry）–《老鼠麻煩》，威廉·漢納（William Hanna）和約瑟夫·巴貝拉（Joseph Barbera）

假設(shè)我們要實(shí)現(xiàn)一個(gè)DateBuilder ，它將以經(jīng)典的dd.mm.yyyy格式（可能還帶有其他類型的分隔符，不僅. ）生成一個(gè)String 。 為了簡單起見，我們將只關(guān)注格式，而忽略諸如一個(gè)月中的天數(shù)，leap年之類的情況。首先是界面：

public interface DateBuilder {DateBuilder addDay(final Integer day);DateBuilder addMonth(final Integer month);DateBuilder addYear(final Integer year);DateBuilder addSeparator(final String sep);String build();}

上面的接口將有五個(gè)實(shí)現(xiàn)： StringDateBuilder （公共入口點(diǎn)）， ExpectSeparator ， ExpectMonth ， ExpectYear和ExpectBuild （這四個(gè)包均受程序包保護(hù)，對(duì)用戶不可見）。 StringDataBuilder看起來像這樣：

public final class StringDateBuilder implements DateBuilder {private final StringBuilder date = new StringBuilder();@Overridepublic DateBuilder addDay(final Integer day) {this.date.append(String.valueOf(day));return new ExpectSeparator(this.date);}@Overridepublic DateBuilder addMonth(final Integer month) {throw new UnsupportedOperationException("A day is expected first! Use #addDay!");}@Overridepublic DateBuilder addYear(final Integer year) {throw new UnsupportedOperationException("A day is expected first! Use #addDay!"); }@Overridepublic DateBuilder addSeparator(final String sep) {throw new UnsupportedOperationException("A day is expected first! Use #addDay!");}@Overridepublic String build() {throw new UnsupportedOperationException("Nothing to build yet! Use #addDay!");}}

我相信您已經(jīng)明白了：其他四個(gè)實(shí)現(xiàn)將處理它們自己的情況。 例如， ExpectSeparator將從addSeparator(...)之外的所有方法中引發(fā)異常，在該方法中，它將分隔符附加到StringBuilder并返回ExpectMonth的實(shí)例。 最后，這臺(tái)機(jī)器的最后一個(gè)節(jié)點(diǎn)將是ExpectBuild （在添加年份之后由ExpectYear返回），它將拋出build()之外所有方法的異常。

這種設(shè)計(jì)幫助我將代碼對(duì)象保持較小，沒有標(biāo)志和if/else分支。 與往常一樣，上面的每個(gè)類都易于測試，并且通過切換返回的實(shí)現(xiàn)，可以輕松更改構(gòu)建器的行為。

當(dāng)然，我不是唯一想到這些的人：先生。 尼古拉斯·弗蘭克（NicolasFr?nkel）就在上個(gè)月在這里寫下了這個(gè)想法。 但是，我覺得有必要帶走我的兩分錢，因?yàn)槲也煌耆矚g他的例子：他為構(gòu)建器的節(jié)點(diǎn)使用了不同的接口，以保持構(gòu)建器的安全性和防白癡性（例如，甚至不允許用戶查看addMonth或build方法（如果他們不應(yīng)該使用的話）。 我不同意這一點(diǎn)，因?yàn)檫@意味著我需要管理更多的代碼，此外，客戶端將與構(gòu)建者的邏輯相結(jié)合。 我寧愿只強(qiáng)制用戶到學(xué)習(xí)如何使用生成器（它不應(yīng)該是他們的一個(gè)大的努力，因?yàn)樗麄儜?yīng)該搭上一個(gè)最簡單的單元測試任何異常，對(duì)不對(duì)？ 吧... ）

我也找到了這篇文章 ，它提供了更廣泛，更理論上的解釋，并不一定與Builder模式相關(guān)聯(lián)-如果您考慮一下，這種方法可以用于任何必須根據(jù)其內(nèi)部狀態(tài)更改其行為的對(duì)象。

翻譯自: https://www.javacodegeeks.com/2018/12/builder-fail-fast-state-machine.html

總結(jié)

以上是生活随笔為你收集整理的生成器作为（快速失败）状态机的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。