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

MartinFowler

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

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

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实践

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有什么用

no ip domain-lookup

patterns, principles, and practices of domain-driven design mobi pdf

real origin_x = domain->org[0]；是什么意思

add_header X-Permitted-Cross-Domain-Policies ""master-only"";

access is denied, please check whether the [domain-username-password] are co

tomcat8.5如何通过配置文件解决X-Download-Options，X-Permitted-Cross-Domain-Policies，Referrer-Policy，X-Frame-Options，X-Content-Type-Options头缺失问题

什么是Domain-Adversarial Learning

grails create-domain-class user例子

Domain adaptation

no ip domain-look是什么意思

长春人文学院在河北2021-2024各专业最低录取分数及位次表.pdf

最新资源