quartus状态机生成_生成器作为（快速失败）状态机

quartus状态机生成

这个想法是几周前在设计“生成器”类时想到的，该类必须将输入发送给封装的Writer 。实际上，它是Builder模式。但是，规则有些复杂，用户必须以某种方式调用add...()方法，才能正确生成输出。

不用说，我不喜欢只有一个BuilderImpl类可以在内部设置和验证各种标志，以便知道什么以及什么时候可以做的选择。解决方案是构建一个有限状态机，因为构建者的界面很流畅。像往常一样，在这篇文章中，我将通过一个例子来说明。

汤姆和杰瑞（Tom＆Jerry）–《老鼠麻烦》，威廉·汉纳（William Hanna）和约瑟夫·巴贝拉（Joseph Barbera）

假设我们要实现一个DateBuilder ，它将以经典的dd.mm.yyyy格式（可能还带有其他类型的分隔符，不仅是. ）生成一个String 。为了简单起见，我们将仅关注格式，而忽略诸如一个月中的天数，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();}

上面的接口将有五个实现： StringDateBuilder （公共入口点）， ExpectSeparator ， ExpectMonth ， ExpectYear和ExpectBuild （这四个是受程序包保护的，对用户不可见）。 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!");}}

我相信您已经明白了：其他四个实现将处理它们自己的情况。例如， ExpectSeparator将从addSeparator(...)之外的所有方法中引发异常，在该方法中，它将分隔符附加到StringBuilder并返回ExpectMonth的实例。最后，这台机器的最后一个节点将是ExpectBuild （在添加年份之后由ExpectYear返回），它将抛出除了build()之外所有方法的异常。

这种设计帮助我将代码对象保持较小，没有标志和if/else分支。与往常一样，上面的每个类都易于测试，并且通过切换返回的实现，可以轻松更改构建器的行为。

当然，我不是唯一想到这些的人。尼古拉斯·弗兰克（NicolasFränkel）就在上个月在这里写下了这个想法。但是，我觉得有必要带走我的两分钱，因为我不完全喜欢他的例子：他为构建器的节点使用了不同的接口，以保持构建器的安全性和防白痴性（例如，甚至不允许用户查看addMonth或build方法（如果他们不应该使用的话）。我不同意这一点，因为这意味着我需要管理更多的代码，此外，客户端将与构建者的逻辑相结合。我宁愿只强制用户到学习如何使用生成器（它不应该是他们的一个大的努力，因为他们应该搭上一个最简单的单元测试任何异常，对不对？吧... ）

我也找到了这篇文章，它提供了更广泛，更理论上的解释，并不一定与Builder模式相关联–如果您考虑一下，这种方法可以用于任何必须根据其内部状态更改其行为的对象。