Do well thought out method/function names create a DSL?

Question

I was thinking, method names and their calls seem to create a DSL in your code, by wrapping up the generic stuff and naming it appropriately for what you're trying to achieve.

You know, so it's easy to reason about what the following means

if (a.isSubReportOf(b) || b.isSubReportOf(a)) {
    // do stuff
}

but the code in the methods might be really difficult to interpret without studying it.

I know that people sometimes think there's something special about this whole DSL thing - do we create them in code all the time?

Answer 1

You could ask alternately if DSL's should be replaced with well thought out class, variable and methods names. I have always come to associate this with Kent Beck, because he's always been a proponent of "writing code that reads like poetry".

You are inventing the domain vocabulary, crafting the grammar of the business operations into objects, methods and variables. Sounds DSL'ish to me ;)

Answer 2

It depends on your definition of DSL, but for me, yes I'd say so. DDD is all about creating abstractions which allow you to have a ubiquitous language and reason about concepts on a higher level. Some may argue it's not a DSL per-se, but the more important question is, is code like this reasoning about the domain?

I'd say yes, and that's what really matters.

Answer 3

I think you are referring what Martin Fowler (and maybe others) call an Internal DSL. Read this.

Answer 4

Can you replace one by the other in a sufficiently complex or simple situation? Yes

Are they the same? Not at all.

Each have pros and cons and it all depends on what is needed. If you need it to be modifiable at run time, then using function in a compiled language might not be the best solution (it's still possible though) as it will be too heavy for your needs.

The goal of a DSL is to pinpoint your needs and make a language that only encompass those needs so that it's as simple as possible to represent. That way, our limited brains can easily picture what the data is without having to compile a program.

Also, a simple enough DSL could easily be parsed and edited by another program. After all, you made the syntax, and encapsulated it in a library, right?

In your example above:

a.isSubReportOf(b) || b.isSubReportOf(a)

is still harder to grasp mentally than say:

a <-> b