1.3 为格兰特小姐的控制器编写程序
至此，我们已经实现了状态机模型，接下来，就可以为格兰特小姐的控制器编写程序了，如下所示：
Event doorClosed = new Event("doorClosed", "D1CL");
Event drawerOpened = new Event("drawerOpened", "D2OP");
Event lightOn = new Event("lightOn", "L1ON");
Event doorOpened = new Event("doorOpened", "D1OP");
Event panelClosed = new Event("panelClosed", "PNCL");
Command unlockPanelCmd = new Command("unlockPanel", "PNUL");
Command lockPanelCmd = new Command("lockPanel", "PNLK");
Command lockDoorCmd = new Command("lockDoor", "D1LK");
Command unlockDoorCmd = new Command("unlockDoor", "D1UL");
State idle = new State("idle");
State activeState = new State("active");
State waitingForLightState = new State("waitingForLight");
State waitingForDrawerState = new State("waitingForDrawer");
State unlockedPanelState = new State("unlockedPanel");
StateMachine machine = new StateMachine(idle);
idle.addTransition(doorClosed, activeState);
idle.addAction(unlockDoorCmd);
idle.addAction(lockPanelCmd);
activeState.addTransition(drawerOpened, waitingForLightState);
activeState.addTransition(lightOn, waitingForDrawerState);
waitingForLightState.addTransition(lightOn, unlockedPanelState);
waitingForDrawerState.addTransition(drawerOpened, unlockedPanelState);
unlockedPanelState.addAction(unlockPanelCmd);
unlockedPanelState.addAction(lockDoorCmd);
unlockedPanelState.addTransition(panelClosed, idle);
machine.addResetEvents(doorOpened);
经过查看上述代码，我们发现，它与之前的代码有着很大的不同。之前的代码描述了如何构建状态机模型，而上面这段代码则是在配置一个特定的控制器。我们常常会看到这样一种划分：一方面是程序库（见图1-3）、框架或者组件的实现代码；另一方面是配置代码或组件组装代码。从本质上说，这种做法分开了公共代码和可变代码。用公共代码构建一套组件，然后根据不同的目的进行配置。
配置代码还有另外一种表现形式：
<stateMachine start = "idle">
<event name="doorClosed" code="D1CL"/>
<event name="drawerOpened" code="D2OP"/>
<event name="lightOn" code="L1ON"/>
<event name="doorOpened" code="D1OP"/>
<event name="panelClosed" code="PNCL"/>
<command name="unlockPanel" code="PNUL"/>
<command name="lockPanel" code="PNLK"/>
<command name="lockDoor" code="D1LK"/>
<command name="unlockDoor" code="D1UL"/>
<state name="idle">
<transition event="doorClosed" target="active"/>
<action command="unlockDoor"/>
<action command="lockPanel"/>
</state>
<state name="active">
<transition event="drawerOpened" target="waitingForLight"/>
<transition event="lightOn" target="waitingForDrawer"/>
</state>
<state name="waitingForLight">
<transition event="lightOn" target="unlockedPanel"/>
</state>
<state name="waitingForDrawer">
<transition event="drawerOpened" target="unlockedPanel"/>
</state>
<state name="unlockedPanel">
<action command="unlockPanel"/>
<action command="lockDoor"/>
<transition event="panelClosed" target="idle"/>
</state>
<resetEvent name = "doorOpened"/>
</stateMachine>
大多数读者对这种表现形式应该更熟悉一些：表现为XML文件。这种做法有几个好处。第一个明显的好处是，无须为每个要实现的控制器编译一个单独的Java程序，相反，只要把状态机组件加上相应的解析器编译到一个公共的JAR 里，然后，发布对应的XML文件，当状态机启动时读取这个文件。控制器行为的任何修改都无须发布新的JAR。当然，我们需要为此付出一些代价，许多配置上的语法错误只能在运行时检测出来，虽然各种各样的XML模式系统还能帮上点忙。我还是“广泛测试”（extensive testing）的超级粉丝，广泛测试不仅可以在编译时检查就捕获到大多数错误，还可以发现一些类型检查无法确定的致命问题。有了这种及时测试，就不必担心把错误检测带到运行时。
第二个好处在于文件本身的表现力。我们不必再去考虑通过变量进行连接的细节。相反，我们拥有了一种声明方式，从许多方面来看，这种方式读起来都会更加清晰。这里还有一些限制：这个文件只能表示 配置─这种限制也是有益的，因为它会降低人们编写组装组件代码犯错的概率。
或许，你听说过声明式编程这回事。对我们而言，更常见的模型是命令式（imperative）模型，也就是，用一系列的步骤指挥计算机。“声明式”是一个非常模糊的术语，但是，它通常适用于所有远离了命令式编程的方式。在这里，我们向那个方向迈进了一步：远离变量倒换，用XML的子元素表示状态内的动作和转换。
正是有了这些好处，如此之多的Java和C#的框架才采用XML配置文件配置。现如今，有时我们会觉得自己是在用XML 编写程序，而非自己的主编程语言。
下面是配置代码的另一个版本：
events
doorClosed D1CL
drawerOpened D2OP
lightOn L1ON
doorOpened D1OP
panelClosed PNCL
end
resetEvents
doorOpened
end
commands
unlockPanel PNUL
lockPanel PNLK
lockDoor D1LK
unlockDoor D1UL
end
state idle
actions {unlockDoor lockPanel}
doorClosed => active
end
state active
drawerOpened => waitingForLight
lightOn => waitingForDrawer
end
state waitingForLight
lightOn => unlockedPanel
end
state waitingForDrawer
drawerOpened => unlockedPanel
end
state unlockedPanel
actions {unlockPanel lockDoor}
panelClosed => idle
end
这确实是代码，虽然使用的不是我们所熟悉的语法。实际上，这是一种定制语法，专为这个例子而打造的。相比于XML语法，我认为这种语法更易写，最重要的是，更易读。它更简洁，省却了许多引号和噪音字符，这些是用XML所要忍受的。或许，你的做法不尽相同，但重点在于，我们可以构造自己和团队所喜欢的语法。我们依然可以在运行时加载（就像XML一样），但是，这么做不是必需的（XML也不必这么做），如果想在编译时加载的话。
这样的语言就是领域专用语言，它有着DSL的许多特征。首先，它只适用于非常有限的用途─除了配置这种特定的状态机外，它什么都做不了。这样带来的结果就是，这个DSL非常简单─它没有控制结构，也没有其他的东西。它甚至不是图灵完备的。用这种语言不能编写整个应用，它所能做的只是描述应用一个小的方面。这样做的结果就是，DSL只有同其他语言配合起来，才能完成整个工作。但是，DSL的简单性意味着，它是易于编辑和处理的。
对于编写控制器软件的人而言，这种简单性意味着更容易理解，并且开发人员之外的人也可以理解这种行为。搭建系统的人能够查看这段代码，并且理解它的运作方式，虽然他们无法理解控制器本身的Java代码。即便他们只读了DSL，但对于指出错误或者同Java开发人员进行有效的交流来说，这就足够了。DSL扮演领域专家和业务分析人员之间的交流媒介，虽然构建这种DSL也存在一些实际的困难，但能够在软件开发最困难的交流鸿沟上架起一座桥梁，其益处也让 这种尝试物有所值。
现在，回顾一下XML的表示形式。这是一种DSL吗？我想说，它是。只不过它是用XML的语法载体而已─ 但是它依旧是DSL。这个例子引出了一个设计问题：哪种做法更好：为DSL定制语法，还是使用XML语法？XML更易于解析，因为人们已经熟悉了解析XML。（然而，同为定制语法编写解析器相比，为XML编写解析器花了我同样多的时间。）我要声明一点，定制语法易读得多，至少在这个例子里是这样的。然而，回顾一下这个选择，我们会发现，DSL核心部分的权衡也是一样的。的确，我们可以认为，大多数XML配置文件本质上都是DSL。
看看下面这段代码，它看上去像是这个问题的DSL吗？
event :doorClosed, "D1CL"
event :drawerOpened, "D2OP"
event :lightOn, "L1ON"
event :doorOpened, "D1OP"
event :panelClosed, "PNCL"
command :unlockPanel, "PNUL"
command :lockPanel, "PNLK"
command :lockDoor, "D1LK"
command :unlockDoor, "D1UL"
resetEvents :doorOpened
state :idle do
actions :unlockDoor, :lockPanel
transitions :doorClosed => :active
end
state :active do
transitions :drawerOpened => :waitingForLight,
:lightOn => :waitingForDrawer
end
state :waitingForLight do
transitions :lightOn => :unlockedPanel
end
state :waitingForDrawer do
transitions :drawerOpened => :unlockedPanel
end
state :unlockedPanel do
actions :unlockPanel, :lockDoor
transitions :panelClosed => :idle
end
同之前的定制语言相比，它稍微有些噪音，但依旧相当清晰。与我有相近语言偏好的人可能看出来了，这是Ruby。在创建更可读的代码方面，Ruby给了我许多语法上的支持，因此，我可以使它很像一门定制语言。
Ruby开发人员会把这段代码当做一种DSL。我用到的是Ruby这方面能力的一个子集，表现的想法同使用XML和定制语法是一样的。从本质上说，我是把DSL嵌入Ruby里，用Ruby的子集作为我的语法。从某种程度上来说，这更多地取决于态度，而非其他什么。我选择透过DSL眼镜观看Ruby代码。但这是一个具有长期传统的观点─Lisp程序员通常会考虑在Lisp里创建DSL。
在此，我要指出，文本DSL有两种，称为外部DSL（external DSL）和内部DSL（internal DSL）。外部DSL是指，在主程序设计语言之外，用一种单独的语言表示领域专用语言。这种语言用的可能是定制语法，或者遵循另一种表现的语法，比如XML。内部DSL是指，用通用语言的语法表示的DSL。这种做法就是出于领域专用的目的，而按照某种风格来使用这种语言。
也许有人还听说一个术语，嵌入式DSL（embedded DSL），它是内部DSL的同义词。虽然这个术语应用得相当广泛，但我还是会避免使用它，因为“嵌入式语言”（embedded language）同样适用于在应用中嵌入的脚本语言，比如Excel里的VBA，Gimp里的Scheme。
回过头来考虑一下原来的Java配置代码。它是一种DSL吗？我想说，不是。这段代码感觉像是同API缝合在一起的，而上面的Ruby代码则更有声明式语言的感觉。这是否意味着无法用Java实现内部DSL呢？下面这段代码怎么样？
public class BasicStateMachine extends StateMachineBuilder {
Events doorClosed, drawerOpened, lightOn, panelClosed;
Commands unlockPanel, lockPanel, lockDoor, unlockDoor;
States idle, active, waitingForLight, waitingForDrawer, unlockedPanel;
ResetEvents doorOpened;
protected void defineStateMachine() {
doorClosed. code("D1CL");
drawerOpened. code("D2OP");
lightOn. code("L1ON");
panelClosed.code("PNCL");
doorOpened. code("D1OP");
unlockPanel.code("PNUL");
lockPanel. code("PNLK");
lockDoor. code("D1LK");
unlockDoor. code("D1UL");
idle
.actions(unlockDoor, lockPanel)
.transition(doorClosed).to(active)
;
active
.transition(drawerOpened).to(waitingForLight)
.transition(lightOn). to(waitingForDrawer)
;
waitingForLight
.transition(lightOn).to(unlockedPanel)
;
waitingForDrawer
.transition(drawerOpened).to(unlockedPanel)
;
unlockedPanel
.actions(unlockPanel, lockDoor)
.transition(panelClosed).to(idle)
;
}
}
虽然这段代码格式上有些奇怪，而且用到了一些不常见的编程约定，但它确实是有效的Java。这段代码我愿意称为 DSL；虽然同Ruby DSL相比，它有些乱，但它还是有DSL所需的声明流。
是什么让内部DSL不同于通常的API呢？这是一个很难回答的问题，稍后，在4.1节，我会花更多的时间来讨论，但它会归结为一种流，只不过用的是一种类语言的模糊记法而已。
也许，有人还碰到过内部DSL的另一个术语，连贯接口（fluent interface）。这个术语强调这样一个事实：内部 DSL实际上只是某种形式的API，只不过其设计考虑到了连贯性难以琢磨的质量。鉴于这种差别，最好给非连贯 API一个名字（我用的术语是，命令）查询API（command–query API）。