DSL概念
Martin Fowler defines a domain-specific language (DSL) as “a computer language that’s targeted to a particular kind of problem, rather than a general purpose language that’s aimed at any kind of software problem”
Domain-specific languages aren’t a new idea by any means. DSLs have been around since long before the start of computing. People have always developed specialized
vocabularies for specialized tasks.
Regular expressions and SQL are similarly specialized languages:Both are languages designed for a narrow domain—text processing and database querying, respectively.
Both are focused on letting you express what you mean, not how the implementation should work—that’s left to some magic engine in the background.
The reason these languages are so successful is that the focus they offer is incredibly useful. They reduce the complexity that you need to handle, and they’re flexible in
terms of what you can make them do.
DSL类别
External DSLs
DSLs that exist outside the confines of an existing language. SQL and regular expressions are two examples of external DSLs.
Common tools for building external DSLs include Lex, Yacc, ANTLR, GOLD Parser,
and Coco/R, among others. Those tools handle the first stage, translating text in a
known syntax to a format that a computer program can consume to produce execut-
able output. The part about “producing executable output” is usually left as an exer-
cise for the reader.
Graphical DSLs
uses shapes and lines to express intent rather than using text.
UML is a good example of a graphical DSL
Microsoft has the Visual Studio DSL Tools, which is a framework that allows you
to build tools similar to the class designer and generate code with them.
Fluent interfaces
Fluent interfaces are ways to structure your API so that operations flow naturally and
provide more readable code. They tend to be valid only when used by developersdur-
ing actual development, which limits their scope compared to other DSLs.
new Pipeline("rhino.png")
.Rotate(90)
.Watermark("Mocks")
.RoundCorners(100, Color.Bisque)
.Save("fluent-rhino.png");
User.FindAll(
Where.User.City == "London" &&
Where.User.RegisteredAt>= DateTime.Now.AddMonths(-3)
);
registry.AddInstanceOf<IWidget>()
.WithName("DarkGreen")
.UsingConcreteType<ColorWidget>()
.WithProperty("Color").EqualTo("DarkGreen");
Internal or embedded DSLs
Internal DSLs are built on top of an existing language, but they don’t try to remain
true to the original programming language syntax. They try to express things in a way
that makes sense to both the author and the reader, not to the compiler.
Obviously, the expressiveness of an internal DSL is limited by whatever constraints
are imposed by the underlying language syntax. You can’t build a good DSL on top of
C# or Java; they have too much rigidity in their syntax to allow it. You probably could
build a good DSL on C++, but it would probably include preprocessor macros galore,
and I wouldn’t place any bets on how maintainable it would be.
The popular choices for building internal DSLs are dynamic languages; Lisp and
Smalltalk were probably the first common choices. Today, people mostly use Ruby,
Python, and Boo.
Rake
task :default => [:test]
task :test do
ruby "test/unittest.rb"
end
Other features that usually appear in dynamic languages are also useful when building DSLs: closures, macros, and duck typing.
The major advantage of an internal DSL is that it takes on all the power of the lan-
uage it’s written for. You don’t have to write the semantics of an if statement, or
edefine operator precedence, for instance. Sometimes that’s useful, and in one of my
DSL implementations I did redefine the if statement, but that’s probably not a good
hing to do in general, and it’s rarely necessary.
A DSL built on top of an existing language can also be problematic, because you
want to limit the options of the language to clarify what is going on. The DSL
houldn’t be a full-fledged programming language; you already have that in the base
anguage, after all.
The main purpose of an internal DSL is to reduce the amount of work required to
make the compiler happy and increase the clarity of the code in question.
The other purpose is to expose the domain. A DSLshould be readable by someone who is familiar with the domain, not the programming language.
为什么要写DSL
l 技术DSL：Making a technical issue or task simpler
This works well if your target audience is developers.
l 业务DSL：Expressing rules and actions in a way that’s close to the domain and understandable to businesspeople
A business DSL needs to be (at the very least) readable to a businessperson with no
background in programming. This type of DSL is mainly expressive in terms of the
domain, and it has a lot less emphasis on the programming features that may still exist.
l 扩展、自动化类的DSL : Automating tasks and actions, usually as part of adding scriptability and extensibility features to your applications.Automatic or extensible DSLs may also be called IT DSLs. This type of DSL is often
used to expose the internals of an application to the outside world.
如：Modern games are usually engines configured with some sort of scripting language. Another use for this style of DSL would be to get into the internals of an application and manage it.
参考图书： DSLs in Boo Domain-Specific Languages in .NET