马丁·福勒的领域特定语言设计与实现指南

需积分: 28 166 浏览量更新于2024-07-25 收藏 5.76MB PDF 举报

《领域特定语言》(DomainSpecificLanguages)是由著名IT专家马丁·福勒(Martin Fowler)所著的一本专业书籍，收录于Addison-WesleyProfessional出版社的系列中。该书出版日期为2010年9月24日，印刷版ISBN分别为0-321-71294-3和978-0-321-71294-3，电子版则有0-13-210754-6和978-0-13-210754-9。全书共640页，适合对领域特定语言有深入研究或实践需求的读者参考。本书分为四章，详细探讨了领域特定语言的概念、设计与实现方法，以及其在实际项目中的应用。首先，通过一个介绍性的例子——Gothic Security，展示了领域特定语言在安全领域的应用。作者引入了状态机模型，解释了如何编程来控制Gothic Security系统，并讨论了语言和语义模型的重要性。第二章深入探讨了如何使用领域特定语言。作者阐述了定义DSL的策略，包括为何选择使用DSL以及可能遇到的问题。他还强调了更广泛的语言处理过程，包括DSL的生命周期管理和设计良好的DSL设计原则。第三章重点关注DSL的实现。章节中详细讲解了DSL处理架构，解析器的工作原理，语法、语义的构建，以及如何解析数据。此外，还涉及了宏的使用，这在内部DSL的实现中扮演着关键角色。第四章聚焦于内部DSL的实施，介绍了两种常见的API风格：Fluent API（连续调用接口）和Command-Query Separation (CQS)。作者强调了解析层的必要性，以及如何通过函数实现更高效的语言处理。《领域特定语言》是一本深度剖析领域特定语言设计、实现及应用的专业指南，它不仅提供了理论框架，还为开发者提供了解决实际问题的实用工具和技术。对于希望深入了解并运用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页未读，继续阅读

u011142525

粉丝: 0
资源: 3

马丁·福勒的领域特定语言设计与实现指南

Domain Specific Languages(martin fowler)

Implementing Domain Specific Languages with Xtext and Xtend(2nd) mobi

Implementing Domain Specific Languages with Xtext and Xtend(2nd) 无水印pdf

DSLs in Boo Domain Specific Languages in .NET

DSLs in Boo Domain Specific Languages in .Net

The Definitive ANTLR Reference--Building Domain Specific Languages.

Implementing Domain Specific Languages with Xtext and Xtend(2nd) epub

The Definitive ANTLR Reference--Building Domain Specific Languages.pdf

Domain-Specific Languages in R--2018

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

最新资源