DSL设计与实现探索

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

"《Domain-Specific Languages》是马丁·福勒（Martin Fowler）撰写的一本书，由Addison-Wesley Professional出版社出版，发行日期为2010年9月24日。该书探讨了领域特定语言（DSL）的相关主题，包括DSL的设计、实现和应用。书中还涉及代码生成、语言工作台以及DSL生命周期等多个方面。" 正文：《Domain-Specific Languages》这本书深入浅出地介绍了DSL的概念和实践，旨在帮助读者理解如何在特定领域内创建和使用自己的语言。DSL是一种专门为某一特定领域设计的语言，它能够提高该领域的开发效率，降低理解和维护的复杂性。第1章“一个引入性的例子”通过Gothic Security的案例，展示了DSL如何用于简化复杂系统的表示。书中提到的状态机模型是DSL的一个常见应用场景，用来描述系统的行为。在编程Miss Grant的控制器部分，作者阐述了如何利用DSL来更清晰地表达控制逻辑。这部分还讨论了DSL与语义模型的关系，以及代码生成在DSL中的作用，指出DSL可以减少手动编码的工作量。第2章“使用领域特定语言”中，作者探讨了定义DSL的原因和方式。他指出DSL可以提升生产力，降低出错率，但同时也可能带来维护难题。此外，DSL的生命周期被分为设计、实现、使用和演化等阶段。本章还讨论了良好DSL设计的关键要素。第3章“实现DSL”介绍了DSL处理的架构，解析器的工作原理，以及语法、语义和解析数据之间的关系。书中提到宏的概念，宏在DSL实现中用于扩展语言功能。第4章“实现内部DSL”聚焦于内部DSL的设计，如流利接口（Fluent API）和命令查询分离（Command-Query Separation）API。书中指出，虽然DSL可以通过函数直接使用，但仍然需要一个解析层来确保语义的正确性。《Domain-Specific Languages》这本书提供了关于DSL的全面视图，从理论到实践，从设计到实现，覆盖了DSL的所有重要方面。对于想要了解和应用DSL的开发者来说，这是一本不可多得的参考资料。书中结合实例的讲解有助于读者更好地理解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页未读，继续阅读

boycesu

粉丝: 0
资源: 6

DSL设计与实现探索

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

Domain-Specific Languages in R--2018

Clojure电子书合集1（12本）

implementing domain-specific languages with xtext and xtend 下载

介绍Domain-specific

DSLs in Action

Aligning Domain-Specific Distribution and Classifier for Cross-Domain Classification from Multiple Sources tensorflow代码

Python eclipse emf

Apache中设置X-Permitted-Cross-Domain-Policies响应头

grails create-domain-class user有什么用

最新资源