More on this book
Kindle Notes & Highlights
operate. In this chapter, we will explore the Domain-Specific Language (DSL) pattern, which looks at the world from the other end of the telescope. The DSL pattern suggests that you should focus on the language itself, not on the interpreter.
DSLs. External DSLs are external in the sense that there is a parser and an interpreter for the DSL,
An internal DSL, again according to Fowler, is one in which we start with some implementation language, perhaps Ruby, and we simply bend that one language into being our DSL. If we are using Ruby to implement our DSL—
Finally, if security is an issue, stay away from internal DSLs—far, far away. After all, the whole point of an internal DSL is that you take some arbitrary code that someone else wrote and suck it into your program. That requires a toothbrush-sharing level of trust.
This custom-tailoring technique is particularly useful when you have lots of orthogonal features that you need to assemble into a single object. By simply manufacturing an object to specification, you can avoid creating a whole host of classes with names like WoodyStemmedNeedleLeafFloweringPlant and VinyStemmedBroadLeafNonfloweringPlant.
Sometimes the best way to approach a task like this one is to imagine what we want the end result to look like and then work backward to an implementation.
While the other patterns mostly dealt on the smaller scale of pulling together a number of related classes, Convention Over Configuration is concerned with pulling together whole applications and application frameworks.
Name your adapter class <protocol>Adapter.
Name your adapter class <protocol>Adapter and put it in the adapter directory.
one of the principles of good interface design is to provide the user with templates and samples to help get started. At one end of the spectrum, we might provide a few examples showing how to create a protocol adapter or an authorizer. At the other end of the spectrum, we could supply a utility to generate the outline or scaffold of a class.
Another potential source of trouble is the possibility that a system that uses a lot of conventions may seem like it is operating by magic to the new user.
But as we work our way through the new wisdom gap, we will uncover even more solutions, new design patterns that will fit the dynamic, flexible world of Ruby. I don’t know what those new patterns will look like, but I do know that I can’t wait to see them. I also know that it is a great time to be a programmer.
