1

メソッド名とその呼び出しは、一般的なものをまとめて、達成しようとしているものに適切な名前を付けることで、コード内に DSL を作成しているように見えます。

ご存知のとおり、次の意味を理解するのは簡単です

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

しかし、メソッド内のコードは、勉強しないと解釈するのが非常に難しい場合があります。

この DSL 全体に何か特別なものがあると考える人がいることは知っています。常にコードでそれらを作成しているのですか?

4

4 に答える 4

2

Martin Fowler (およびおそらく他の人) が内部 DSL と呼んでいるものについて言及していると思います。これを読んでください。

于 2009-02-10T21:51:09.313 に答える
1

DSL をよく考え抜かれたクラス、変数、およびメソッド名に置き換える必要があるかどうか、代わりに尋ねることもできます。ケント・ベックは常に「詩のように読めるコードを書く」ことを支持してきたので、私はいつもこれをケント・ベックと関連付けるようになりました。

あなたはドメイン語彙を発明し、ビジネス オペレーションの文法をオブジェクト、メソッド、および変数に作り上げています。私には DSL っぽいですね ;)

于 2009-02-10T21:43:56.990 に答える
1

DSL の定義にもよりますが、私にとってはそうです。DDD とは、ユビキタスな言語を使用し、より高いレベルで概念について説明できるようにする抽象化を作成することです。それ自体は DSL ではないと主張する人もいるかもしれませんが、より重要な問題は、このようなコードがドメインについて推論しているのかということです。

はい、それが本当に重要なことです。

于 2009-02-10T21:45:09.703 に答える
1

十分に複雑または単純な状況で、一方を他方に置き換えることができますか? はい

彼らは同じですか？全くない。

それぞれに長所と短所があり、必要なものによって異なります。実行時に変更可能にする必要がある場合、コンパイルされた言語で関数を使用することは、ニーズに対して重すぎるため、最適な解決策ではない可能性があります (それでも可能ですが)。

DSL の目標は、ユーザーのニーズを正確に特定し、それらのニーズのみを包含する言語を作成して、できるだけ簡単に表現できるようにすることです。そうすれば、私たちの限られた頭脳は、プログラムをコンパイルしなくても、データが何であるかを簡単に想像できます。

また、十分に単純な DSL は、別のプログラムで簡単に解析および編集できます。結局、構文を作成し、ライブラリにカプセル化しましたね。

上記の例では：

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

次のように言うよりも、精神的に把握するのはまだ難しいです。

a <-> b
于 2009-02-10T21:51:09.563 に答える