Well up here we have entered minimally in the world of DSL, now see a little more in depth this fascinating subject.
If you think about it in the examples above we can clearly see that one of the important aspects of DSL is the understanding of the context. Just as in the past examples of people using the jargon of a particular language, those terms very particular that only had meaning for those familiar with that particular field, clearly comprehended the ideas they wished to convey, and they had a full knowledge of context so the DSL can avail of these properties and thus will be more like a code language human.
Now consider the following code, which corresponds to an order of pizza
This code can clearly see that the way to order a pizza in our code is very different from we can use our common language. DSL will allow us to use our knowledge of the context code. One of the important things you can get to involve the use of a reduced and more perished sintaxys the colloquial speech may be the elimination of noise or interference caused by the code that lies at the APIs that we invoke.
Well before seeing a bit of code, and returning to quote Martin Fowler, there are two types of internal and external DSLs. The internal DSLs are little languages \u200b\u200bdeveloped on top of other languages \u200b\u200b(most extensive in terms of the contexts that span). LINQ is a good example of an internal DSL because for example the LINQ syntax we use is a valid C # syntax, but represents an extended syntax for a domain and more specific. An external DSL describes a language created a lexicon and an interpreter determind where we create our own syntax. SQL is a good example of an external DSL, someone has written for SQL grammar and how to interpret the grammar in other executable code. Parsers and lexers are issues largely beyond the intention of this post. That's why we focus on the fascinating world of internal DSL for now. FLUENT
INTERFACES
A Fluent interface (or "fluent interface?, Certainly not if the translation is applied and did not see or hear the term in English yet), it is only common or regular code written in a way that remove the extra syntax and create sentences. In standard languages, standard 'means here that humans speak, a sentence or phrase or sentence (English sentence) is a complete unit of thought. A fluen interface, try to generate the same result by more sophisticated use of the syntax of a programming language.
For example, consider a different version of the code earlier pizza order
This version is almost as concise as you can order pizza in English or any language normal, and so is still code C # valid, with some creativity. We can see as well as the attempt to create a Fluent Interface Unit of thought. In the above example we can only see the end of the use of the object code when it changes to another object of some kind, in contrast to the fluent interface version we get a complete unit of thought. While in ordinary language the dot indicates a complete unit of thought in the fluent interfaces use the semicolon (;) to finish a complete unit of thought.
The question that may arise to see this different way of writing the code, is why create a fluent interface eat this? If after all the first version of the code was very clear to any developer, but for any other person other than a developer of software and learn the syntax of C # first form can be a little more costoza to read and interpret than the second. As an example I will cite the example quoted by Neal Ford's article on which you base me to write this post, Neal tells us that in some occasion to work on a project about leasing rail cars, had test cases which had to setear complex objects with complex properties as well as the rail industry has elaborate rules about the use of certain types of cars, to check that they were testing the right characteristics of these cars are business analysts showed the code as follows:
While this code is perfectly readable for us developers a long time analysts were trying to ignore the noise introduced by artifacts necesria of code. It was then decided to re write the code in an interface with fluen order to make the code more readable for analysts. This result can be seen here:
The result was satisfactory, it is said in the article above. The slots in the fluent interfaces is not to make the code can be written by non-technical, but if you can read the code, it meant one less level of disengagement between developers and other people.
To conclude this first contact with DSLs, in my opinion it can be said that in essence mean a lot more than re-write our code with a different indentation, how powerful this form of writing code I think, lies in its concept, which will Beyond making the code more readable, and that gives us the opportunity to write our code so that this reflects A more natural way our thinking, as well as normal speech does with our ideas. This way of writing code more "natural" is one of the things that most attracts me personally the concept of DSLs. At the end of this post I'll paste the full code of the fluent interface pizza order to see how you can build in C #. For an upcoming post
leave the implementation of a complete example in C # from a fluen interface, to address the details of implementation so that implies.
(A code then order pizza) using
If you think about it in the examples above we can clearly see that one of the important aspects of DSL is the understanding of the context. Just as in the past examples of people using the jargon of a particular language, those terms very particular that only had meaning for those familiar with that particular field, clearly comprehended the ideas they wished to convey, and they had a full knowledge of context so the DSL can avail of these properties and thus will be more like a code language human.
Now consider the following code, which corresponds to an order of pizza
1: static void Main ( string [] args )
2: {
3: pizza Pizza = new pizza ();
4: Pizza . size = pizza. pizzaSize . girl;
5: Pizza . tomato = true ;
6: Pizza . olives = false ;
7:}
This code can clearly see that the way to order a pizza in our code is very different from we can use our common language. DSL will allow us to use our knowledge of the context code. One of the important things you can get to involve the use of a reduced and more perished sintaxys the colloquial speech may be the elimination of noise or interference caused by the code that lies at the APIs that we invoke.
Well before seeing a bit of code, and returning to quote Martin Fowler, there are two types of internal and external DSLs. The internal DSLs are little languages \u200b\u200bdeveloped on top of other languages \u200b\u200b(most extensive in terms of the contexts that span). LINQ is a good example of an internal DSL because for example the LINQ syntax we use is a valid C # syntax, but represents an extended syntax for a domain and more specific. An external DSL describes a language created a lexicon and an interpreter determind where we create our own syntax. SQL is a good example of an external DSL, someone has written for SQL grammar and how to interpret the grammar in other executable code. Parsers and lexers are issues largely beyond the intention of this post. That's why we focus on the fascinating world of internal DSL for now. FLUENT
INTERFACES
A Fluent interface (or "fluent interface?, Certainly not if the translation is applied and did not see or hear the term in English yet), it is only common or regular code written in a way that remove the extra syntax and create sentences. In standard languages, standard 'means here that humans speak, a sentence or phrase or sentence (English sentence) is a complete unit of thought. A fluen interface, try to generate the same result by more sophisticated use of the syntax of a programming language.
For example, consider a different version of the code earlier pizza order
1: static void Main ( string [] args )
2: {
3: pizza p =
4: pizza . describedAs
5: . Size ( pizza. pizzaSize . large )
6: . Tomato
7: . Olives ;
8: }
This version is almost as concise as you can order pizza in English or any language normal, and so is still code C # valid, with some creativity. We can see as well as the attempt to create a Fluent Interface Unit of thought. In the above example we can only see the end of the use of the object code when it changes to another object of some kind, in contrast to the fluent interface version we get a complete unit of thought. While in ordinary language the dot indicates a complete unit of thought in the fluent interfaces use the semicolon (;) to finish a complete unit of thought.
The question that may arise to see this different way of writing the code, is why create a fluent interface eat this? If after all the first version of the code was very clear to any developer, but for any other person other than a developer of software and learn the syntax of C # first form can be a little more costoza to read and interpret than the second. As an example I will cite the example quoted by Neal Ford's article on which you base me to write this post, Neal tells us that in some occasion to work on a project about leasing rail cars, had test cases which had to setear complex objects with complex properties as well as the rail industry has elaborate rules about the use of certain types of cars, to check that they were testing the right characteristics of these cars are business analysts showed the code as follows:
1: ICar car = new Car ();
2: IMarketingDescription desc = new MarketingDescription ();
3: desc . Type = "Box" ;
4: desc . SubType = "Insulated" ;
5: desc . Lenght = 50 ;
6: desc . Ladder = true ;
7: desc. LinningType = LinningType . CORK ;
8: car. Description desc = ;
9: While this code is perfectly readable for us developers a long time analysts were trying to ignore the noise introduced by artifacts necesria of code. It was then decided to re write the code in an interface with fluen order to make the code more readable for analysts. This result can be seen here:
1: iCar car Car = . describedAs
2: . Box
3: . Insulated
4: . Length ( 50 )
5: . Includes ( Equipment . LADDER )
6: . Has ( Lining . CORK )
The result was satisfactory, it is said in the article above. The slots in the fluent interfaces is not to make the code can be written by non-technical, but if you can read the code, it meant one less level of disengagement between developers and other people.
To conclude this first contact with DSLs, in my opinion it can be said that in essence mean a lot more than re-write our code with a different indentation, how powerful this form of writing code I think, lies in its concept, which will Beyond making the code more readable, and that gives us the opportunity to write our code so that this reflects A more natural way our thinking, as well as normal speech does with our ideas. This way of writing code more "natural" is one of the things that most attracts me personally the concept of DSLs. At the end of this post I'll paste the full code of the fluent interface pizza order to see how you can build in C #. For an upcoming post
leave the implementation of a complete example in C # from a fluen interface, to address the details of implementation so that implies.
(A code then order pizza) using
System;
using System. Collections . Generic ;
using System. Linq ;
using System. Text ;
namespace ConsoleApplication1
{public class pizza
{public enum pizzaSize { girl , large, medium
static} public pizza describedAs
{
get
{
return new pizza ();
}
}
public pizza Size ( pizzaSize sizeValue )
{
size = sizeValue ;
return this ;
}
public pizza Tomate
{
get
{
tomate = true ;
return this ;
}
}
public pizza Aceitunas
{
get
{
aceitunas = true ;
return this ;
}
}
public pizzaSize size { get ; private set ; }
public bool tomate { get ; private set ; }
public bool aceitunas { get ; private set ; }
}
}
[ TestMethod ]
public void TestMethod1 ()
{
ConsoleApplication1 . pizza p = ConsoleApplication1 . pizza . describedAs
. Aceitunas
. Tomate
. Size ( ConsoleApplication1 . pizza . pizzaSize . grande );
Assert . IsTrue ( p . aceitunas );
Assert . IsTrue (p . tomato );
Assert . AreEqual (p . size , ConsoleApplication1 . pizza . pizzaSize . great );}
