马丁·福勒的DSL探索： Domain-Specific Languages实践

5星 · 超过95%的资源需积分: 28 119 浏览量更新于2024-07-27 收藏 5.76MB PDF 举报

"马丁·福勒的《领域特定语言》(Domain-Specific Languages)是一本经典著作，由Addison-Wesley Professional出版社于2010年9月24日出版，ISBN-10为0-321-71294-3，ISBN-13为978-0-321-71294-3。书中探讨了DSL（领域特定语言）的概念、设计与实现，并涵盖了代码生成、语言工作台、可视化等多个方面。" 《领域特定语言》是马丁·福勒对于DSL深入研究的成果，旨在帮助读者理解和利用DSL来提高软件开发的效率和质量。DSL是一种专门针对某一特定领域的编程语言，它可以更直观、高效地表达该领域的概念和规则，相比通用编程语言，DSL能更好地服务于特定应用。在第一章中，福勒通过一个名为“Gothic Security”的示例，引入了状态机模型，展示了如何编程实现Miss Grant's Controller，从而引出DSL的使用以及代码生成和语言工作台的作用。DSL不仅用于编程，还用于数据解析、宏等语言处理任务。书中的第二章讨论了DSL的设计和使用，包括为何使用DSL（如提高生产力、减少错误等），DSL可能遇到的问题，以及DSL的生命周期。作者还提出了构建良好DSL设计的原则。第三章聚焦于DSL的实现，特别是解析器的工作原理，以及语法、语义之间的关系。书中详细介绍了如何解析数据和使用宏来扩展语言功能。第四章则关注内部DSL的实现，探讨了Fluent API和命令查询API的设计，解释了为何需要解析层，并展示了如何利用函数来构建DSL。这本书不仅适合软件开发者阅读，也适合任何希望深入理解领域特定语言的读者，无论是在软件架构、工具设计还是开发流程优化方面，都能从中获得宝贵的见解。通过学习《领域特定语言》，读者可以掌握创建自己的DSL技能，以提升工作效率，解决特定领域的复杂问题。

For this example, I'll focus on this control program. Each customer has individual needs, but

once you look at a good sampling, you will soon see common patterns. Miss Grant closes her

bedroom door, opens a drawer, and turns on a light to access a secret compartment. Miss

Shaw turns on a tap, then opens either of her two compartments by turning on the correct

light. Miss Smith has a secret compartment inside a locked closet inside her office. She has

to close a door, take a picture off the wall, turn her desk light on three times, open the top

drawer of her filing cabinet—and then the closet is unlocked. If she forgets to turn the desk

light off before she opens the inner compartment, an alarm will sound.

Although this example is deliberately whimsical, the underlying point isn't that unusual. What

we have is a family of systems that share most components and behaviors, but have some

important differences. In this case, the way the controller sends and receives messages is

the same across all the customers, but the sequence of events and commands differs. We

want to arrange things so that the company can install a new system with the minimum of

effort, so it must be easy for them to program the sequence of actions into the controller.

Looking at all these cases, it emerges that a good way to think about the controller is as a

state machine. Each sensor sends an event that can change the state of the controller. As

the controller enters a state, it can send a command message out to the network.

At this point, I should confess that originally in my writing it was the other way around. A

state machine makes a good example for a DSL, so I picked that first. I chose a gothic castle

because I get bored of all the other state machine examples.

Miss Grant's Controller

Although my mythical company has thousands of satisfied customers, we'll focus on just

one: Miss Grant, my favorite. She has a secret compartment in her bedroom that is normally

locked and concealed. To open it, she has to close the door, then open the second drawer in

her chest and turn her bedside light on—in either order. Once these are done, the secret

panel is unlocked for her to open.

I can represent this sequence as a state diagram ( Figure 1.1 ).

Figure 1.1. State diagram for Miss Grant's secret compartment

If you haven't come across state machines yet, they are a common way of describing

behavior—not universally useful but well suited to situations like this. The basic idea is that

the controller can be in different states. When you're in a particular state, certain events will

transition you to another state that will have different transitions on it; thus a sequence of

events leads you from state to state. In this model, actions (sending of commands) occur

when you enter a state. (Other kinds of state machines perform actions in different places.)

This controller is, mostly, a simple and conventional state machine, but there is a twist. The

customers' controllers have a distinct idle state that the system spends most of its time in.

Certain events can jump the system back into this idle state even if it is in the middle of the

more interesting state transitions, effectively resetting the model. In Miss Grant's case,

opening the door is such a reset event.

Introducing reset events means that the state machine described here doesn't quite fit one

of the classical state machine models. There are several variations of state machines that are

pretty well known; this model starts with one of these but the reset events add a twist that

is unique to this context.

In particular, you should note that reset events aren't strictly necessary to express Miss

Grant's controller. As an alternative, I could just add a transition to every state, triggered

by doorOpened, leading to the idle state. The notion of a reset event is useful because it

simplifies the diagram.

The State Machine Model

Once the team has decided that a state machine is a good abstraction for specifying how the

controllers work, the next step is to ensure that abstraction is put into the software itself. If

people want to think about controller behavior with events, states, and transitions, then we

want that vocabulary to be present in the software code too. This is essentially the Domain-

Driven Design principle of Ubiquitous Language [evans-ddd]—that is, we construct a shared

language between the domain people (who describe how the building security should work)

and programmers.

When working in Java, the natural way to do this is through a Domain Model [poeaa] of a

state machine.

Figure 1.2. Class diagram of the state machine framework

The controller communicates with the devices by receiving event messages and sending

command messages. These are both four-letter codes sent through the communication

channels. I want to refer to these in the controller code with symbolic names, so I create

event and command classes with a code and a name. I keep them as separate classes (with

a superclass) as they play different roles in the controller code.

class AbstractEvent...

private String name, code;

public AbstractEvent(String name, String code) {

this.name = name;

this.code = code;

}

public String getCode() { return code;}

public String getName() { return name;}

public class Command extends AbstractEvent

public class Event extends AbstractEvent

The state class keeps track of the commands that it will send and its outbound transitions.

class State...

private String name;

private List<Command> actions = new ArrayList<Command>();

private Map<String, Transition> transitions = new HashMap<String, Transition>();

class State...

public void addTransition(Event event, State targetState) {

assert null != targetState;

transitions.put(event.getCode(), new Transition(this, event, targetState));

}

class Transition...

private final State source, target;

private final Event trigger;

public Transition(State source, Event trigger, State target) {

this.source = source;

this.target = target;

this.trigger = trigger;

}

public State getSource() {return source;}

public State getTarget() {return target;}

public Event getTrigger() {return trigger;}

public String getEventCode() {return trigger.getCode();}

The state machine holds on to its start state.

class StateMachine...

private State start;

public StateMachine(State start) {

this.start = start;

}

Then, any other states in the machine are those reachable from this state.

class StateMachine...

public Collection<State> getStates() {

List<State> result = new ArrayList<State>();

collectStates(result, start);

return result;

}

private void collectStates(Collection<State> result, State s) {

if (result.contains(s)) return;

result.add(s);

for (State next : s.getAllTargets())

collectStates(result, next);

}

class State...

Collection<State> getAllTargets() {

List<State> result = new ArrayList<State>();

for (Transition t : transitions.values()) result.add(t.getTarget());

return result;

}

To handle reset events, I keep a list of them on the state machine.

class StateMachine...

private List<Event> resetEvents = new ArrayList<Event>();

public void addResetEvents(Event... events) {

for (Event e : events) resetEvents.add(e);

}

I don't need to have a separate structure for reset events like this. I could handle this by

simply declaring extra transitions on the state machine like this:

class StateMachine...

private void addResetEvent_byAddingTransitions(Event e) {

for (State s : getStates())

if (!s.hasTransition(e.getCode())) s.addTransition(e, start);

}

I prefer explicit reset events on the machine because that better expresses my intent. While

it does complicate the machine a bit, it makes it clear how a general machine is supposed to

work, as well as the intention of defining a particular machine.

With the structure out of the way, let's move on to the behavior. As it turns out, it's really

quite simple. The controller has a handle method that takes the event code it receives from

the device.

class Controller...

private State currentState;

private StateMachine machine;

public CommandChannel getCommandChannel() {

return commandsChannel;

}

private CommandChannel commandsChannel;

public void handle(String eventCode) {

if (currentState.hasTransition(eventCode))

transitionTo(currentState.targetState(eventCode));

else if (machine.isResetEvent(eventCode))

transitionTo(machine.getStart());

// ignore unknown events

}

private void transitionTo(State target) {

currentState = target;

currentState.executeActions(commandsChannel);

}

class State...

public boolean hasTransition(String eventCode) {

return transitions.containsKey(eventCode);

}

public State targetState(String eventCode) {

return transitions.get(eventCode).getTarget();

}

public void executeActions(CommandChannel commandsChannel) {

for (Command c : actions) commandsChannel.send(c.getCode());

}

class StateMachine...

public boolean isResetEvent(String eventCode) {

return resetEventCodes().contains(eventCode);

}

private List<String> resetEventCodes() {

List<String> result = new ArrayList<String>();

for (Event e : resetEvents) result.add(e.getCode());

return result;

}

It ignores any events that are not registered on the state. For any events that are

recognized, it transitions to the target state and executes any commands defined on that

target state.

Programming Miss Grant's Controller

Now that I've implemented the state machine model, I can program Miss Grant's controller like this:

Code View: Scroll / Show All

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);

剩余411页未读，继续阅读

daniyyel

粉丝: 0
资源: 1

马丁·福勒的DSL探索： Domain-Specific Languages实践

Perl语言编程：生物信息学应用及计算生物学编程概述

DSL设计与实现探索

马丁·福勒的《领域特定语言》解析

Domain-Specific Languages in R--2018

implementing domain-specific languages with xtext and xtend 下载

Implementing Domain-Specific Languages with Xtext and Xtend(PACKT,2013)

High-Level-Tool-for-Spreadsheet-Based-Domain-Specific-Languages

A Formal Definition of the Structural Semantics of Domain-Specific Modeling Languages

Language Implementation Patterns Create Your Own Domain-Specific and 无水印原版pdf

The Definitive ANTLR Reference--Building Domain Specific Languages.

最新资源