Evolutionary architecture and emergent design

The previous issue of this series describes how to use a specific domain language (DSL) to capture domain idiomatic patterns. This issue will continue with this topic to showcase various DSL build methods.

In the next book, in Domain specific Languages, Martin Fowler will explain the difference between the two DSLs. External DSLs can build a new syntax that requires tools such as Lexx and Yacc or ANTLR to build. An internal DSL constructs a new language based on the basic language and borrows and styles the syntax of the basic language. This example builds the internal DSLs with Java™ as the base language, building a new small language on top of its syntax.

It is emphasized that building DSLs through all of the following methods is the concept of an implicit context. DSLs (especially internal DSLs) attempts to eliminate the intricacies of syntax by creating contextual wrappers around related elements. A typical example of this concept is the parent element and child element in XML, which provides a wrapper around the related project. You will notice that many of these DSL methods use language grammar techniques to achieve the same effect.

Readability is one of the advantages of using a DSL. If you write code that the non-developers can read, it shortens the feedback loop between your team and the people who are requesting the relevant code functionality. A common DSL pattern identified in Fowler's book is called a coherent interface, which he defines as being capable of relaying or maintaining the instruction context for a series of method calls. I'll show you several coherent interfaces, first, method links.

Method link

The method link uses the return value of the method to relay the instruction context, in which case it is the object instance that made the first method call. That sounds a lot more complicated, so I'm going to use an example to illustrate the concept.

When using DSLs, it is often necessary to start backwards running from the target syntax to figure out how to implement it. Starting at the end of the line is because readability is very important in DSLs. The example I want to use is a small application that tracks calendar entries. The application illustrates the syntax of the DSL, as shown in Listing 1:

Listing 1. Destination syntax for calendar DSL

public class Calendardemochained {

public static void Main (string[] args) {
New Calendardemo Chained (); 　　　　
}

Public calendardemochained () {
Calendar fourpm = Calendar.getinstance ();
Fourpm.set (Calendar.hour_of_day, 16);
Calendar fivepm = Calendar.getinstance ();
Fivepm.set (Calendar.hour_of_day, 17); 　　　　

Appointmentcalendarchained calendar =
New appointmentcalendarchained ();
Calendar.add ("Dentist").
from (fourpm).
to (FIVEPM).
at ("123 Main Street"); 　　　　

Calendar.add ("Birthday Party"). at (fourpm);
Displayappointments (Calendar);　
}

private void displayappointments (appointmentcalendarchained calendar) {
for (appointment a 　　 : Calendar.getappointments ())
System.out.println (a.tostring ());
}
}

After you've processed the necessary tedious settings for the Java calendar above, you can see that the method link is starting to work after I add a value to the two calendar entries. Notice that I use a space to separate that part of a single line of code (from the Java syntax point of view). The behavior of styling the base language to make the DSL more readable is common in internal DSLs.

The appointment class contains most of the consistent interface methods that appear in Listing 2:

Listing 2. Appointment Class

public class Appointment {
Private String _name;
Private String _location;
Private Calendar _starttime;
Private Calendar _endtime;

Public appointment (String name) {
This._name = name;
}

Public appointment () {
}

Public appointment name (String name) {
_name = name;
return this;
}
Public appointment at (String location) {
_location = location;
return this;
}

Public appointment at (Calendar starttime) {
_starttime = StartTime;
return this;
}

Public appointment from (Calendar starttime) {
_starttime = StartTime;
return this;
}

Public appointment to (Calendar Endtime) {
_endtime = Endtime;
return this;
}

Public String toString () {
Return "Appointment:" + _name +
((_location!= null && _location.length () > 0)?
", Location:" + _location: "") +
", Start Time:" + _starttime.get (calendar.hour_of_day) +
(_endtime!= null?) ", End time:" +
_endtime.get (Calendar.hour_of_day): "");
}
}