Kotlinを用いたDSL的な設計手法と使用上の注意

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyrights(c) Henry, Inc. All rights reserved. About Me Kohei Ishikawa / @kohii ● 2021.08〜 Henry Inc. ○ Developer ○ CTO室 Lead Architect ● Indie Hacker ○ Moyuk - ブラウザ上でTypeScriptでツールを作るプラットフォーム ○ MediXplorer - 医科診療行為マスタービューアー ○ SmoothCSV - CSVエディター ○ など ● X: @kohii00

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyrights(c) Henry, Inc. All rights reserved. なぜなら... ● 作って終わりではない ○ 作る時間より、その後保守運用される時間の方が圧倒的に長い ○ コードは様々な理由で修正される ● チームで開発する ○ 自分が作っていないコードの面倒を見る ○ 昨日の自分は他人「そもそも、他人の書いたコードを理解すること自体が既に十分に難しい作業なのです。」 (Vladimir Khorikov「単体テストの考え方/使い方」p.79)

Slide 8

Slide 8 text

Copyrights(c) Henry, Inc. All rights reserved. コードが意図の表現に見えるか、文字の連なりに見えるか ● 前提知識の問題 ○ コードを理解するために学習しないといけないことがどれくらいあるか ○ ドメイン知識、設計指針、過去の経緯、 etc… ● 設計・実装の問題 ○ コードがどれくらい意図をダイレクトに伝えるものになっているか ○ いろいろな要素がある ■ 適切な命名 ■ 適切な構成 ■ 適切な責務 ■ 手続き的 ←→ 宣言的（グラデーション） ■ etc.

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyrights(c) Henry, Inc. All rights reserved. 欠点 ● ミスや見落としが発生しやすい ○ 例えば並列処理の待ち合わせを忘れたりとか、 shutdownする対象のExecutorServiceを間違えたりとか... ● 構造が見えにくい ○ 処理を順に追わないとワークフローの構造が見えてこない ● 本質的なことと副次的なことがごちゃまぜ ○ ワークフロー制御のためのコードとワークフロー内で実行されるタスク本体のコードが混ざっていて読みにくい

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyrights(c) Henry, Inc. All rights reserved. ①ワークフローをモデリングワークフローはファイルシステム（ファイル/ フォルダ）のような木構造で表現できる ● Task ○ 実行対象の処理を持つモデル ○ 木構造の葉となるノード ● Sequential ○ 複数の子ノードを持つ ○ 子ノードは順次実行される ● Parallel ○ 複数の子ノードを持つ ○ 子ノードは並列実行される ○ (オプショナルなパラメータとして並列度も持つ)

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyrights(c) Henry, Inc. All rights reserved. モデルを使ってワークフローを記述 ● コンストラクタでオブジェクトを組み立てる ○ 単にインスタンスを作っているだけだが、ワークフローの構造を宣言的に表現できている ○ この手法を Poor man’s DSL と呼ぶことにする (https://github.com/zsmb13/VillageDSL から借用) ● 細かいところ: ○ Task: コンストラクタの引数がラムダ式だけなので `()` を省略して呼び出せる ○ Parallel / Sequential: コンストラクタ引数を `vararg`（可変長引数）として定義しているので、 `listOf` とかを使わなくても複数の子要素を直接渡せる ○ 組み立てたワークフローは `run` でそのまま実行可能 ②ワークフローを記述

Slide 21

Slide 21 text

Copyrights(c) Henry, Inc. All rights reserved. Poor man’s DSL ● シンプル。他のプログラミング言語でもできる ● Kotlinだとさらに ○ newを書かなくていいのでスッキリ記述できる ○ 名前付き引数でパラメータの意味が明示的になる ● これがDSLの基本 ○ 他のアプローチでも結局このオブジェクト構造を組み立てるのはやる ○ これを如何にスタイリッシュに書けるようにするかで、より “DSL” らしくなっていく

Slide 22

Slide 22 text

Copyrights(c) Henry, Inc. All rights reserved. ● 意図や構造が見えやすい ○ ワークフローの構造がダイレクトに表現される ○ 実行制御等の詳細は仕組み側に隠蔽されるため、本質的なことだけに集中したコードになる ● ミスが発生しにくい ○ DSL利用側は間違える余地が少ない ○ コードを見渡しやすい ● 関心の分離 ○ 業務上の関心事の表現 vs 表現を処理するための内部の仕組み ○ 関心が分離されているとそれぞれ進化させやすい ■ 例1: ExecutorServiceをCoroutineに置き換える ■ 例2: 各タスクの前後にログ出力を仕込む ■ 例3: 失敗したタスクを自動リトライする ■ これらの変更はDSL利用側には手を入れずにでき、しかもすべての利用箇所が恩恵を受ける DSL的なやり方の利点

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyrights(c) Henry, Inc. All rights reserved. 1⃣ 2⃣ 1⃣ Dependency ● 依存先を表すモデル 2⃣ DependenciesBuilder ● `List` を作るためのビルダー ● `api` / `implementation` メソッドを呼び出すと`dependencies` フィールドに `Dependency` のインスタンスが追加される

Slide 27

Slide 27 text

Copyrights(c) Henry, Inc. All rights reserved. 3⃣ dependencies 関数 ● ユーザーに公開する DSL関数本体 ● 引数として関数を受け取る ○ この関数リテラルにはレシーバー ( `DependenciesBuilder.`) が付いているので、関数内からビルダーのインスタンス直接にアクセスできる ● やってること: ○ ビルダーのインスタンスを作って ○ `block` に渡して実行して ○ 実行後のビルダーから `dependencies` を取り出す 3⃣

Slide 28

Slide 28 text

Copyrights(c) Henry, Inc. All rights reserved. さっきのワークフローの例 ● 構造をダイレクトに表現するという意味では Poor man’s DSL と同じ ○ このDSLは先ほどのモデルを組み立てるビルダーとして機能する ● Pros: ○ ちょっとカッコよくなった ○ オプショナルなパラメータである `maxConcurrency` の指定が読みやすくなった ● Cons: ○ 使う側が気持ちよく書ける分、仕組み側の負担が増える ■ モデルの実装に加えてビルダーやDSL関数の実装が増える DSLのコードはこちら: https://github.com/kohii/kotlin-dsl-example

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Copyrights(c) Henry, Inc. All rights reserved. さっきのワークフローの例 ● ワークフローの構造を宣言する代わりに、タスクとタスク間の依存を宣言する DSL ○ `task2 dependsOn task1` =「task2は task1に依存する」=「task2はtask1が終わってから実行する」 ○ 実行順序は依存関係から導き出せる ● 利用者の関心がワークフローの構造ではなく、タスク間の依存関係の場合はベターなDSLと言える ○ (`infix` がこの違いをもたらすわけではないが...) DSLのコードはこちら: https://github.com/kohii/kotlin-dsl-example

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyrights(c) Henry, Inc. All rights reserved. ● òperator fun` で定義できる ○ à.unaryPlus()` → `+a` ○ à.unaryMinus()` → `-a` ○ à.not()` → `!a` ○ à.plus(b)` → à+b` ○ à.minus(b)` → à-b` ○ à.times(b)` → à*b` ○ その他いっぱいある ● Pros: ○ 通常のメソッドより短く書ける ○ ふるまいが演算子の意味と合致する場合に直感的に読める ● Cons: ○ 演算子を一般的な意味と異なる意味で用いた場合に可読性が低下するしくみ

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Copyrights(c) Henry, Inc. All rights reserved. ヘンリーでやったことの紹介前提: ヘンリーには診療報酬制度に基づく医療費の会計機能がある ● 診療報酬制度 = 医療費の計算・請求のルール ○ 提供した医療行為ごとに定められた点数に基づき医療費を計算し、患者や保険組合に請求 ● こんな感じの会計データを作成する ○ ↓は先日耳鼻科にかかったときの明細 ○ 1点10円で、通常そのうちの 3割を会計時に支払う

Slide 36

Slide 36 text

Copyrights(c) Henry, Inc. All rights reserved. 診療報酬制度に基づく会計内容のチェック機能 ● 「ある条件を満たしたらこっちも追加で算定できる」みたいなのがある ○ 例: 初診料（288点）算定時に、6歳未満の場合は乳幼児加算（75点）を算定できる。ただし時間外加算、休日加算、深夜加算を加算する場合は算定できない。 ● ヘンリーに求められる機能: ○ ① 条件を満たしていたら自動で算定する（ or 算定するよう提案する） ○ ② 逆に条件を満たしていないのに算定していたら警告する ○ 元々はそれぞれ手続き的に実装していた

Slide 37

Slide 37 text

Copyrights(c) Henry, Inc. All rights reserved. 算定ルールを定義するDSL ● ※コードは雰囲気 ● ここから次のような挙動を導き出せる ○ ① `baseCost` (初診料) を算定時に、 `requirements` をすべて満たしていた場合、`target` (乳幼児加算) を自動で算定する ○ ② `target` (乳幼児加算) を算定しているが `baseCost` (初診料) が存在しない、もしくは `requirements` を満たさない場合は警告する

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyrights(c) Henry, Inc. All rights reserved. 利用する側が多いほど仕組みを凝るコストが見合う DSLを利用する側の数アプローチメモ少 DSL化しない利用箇所が少ないなら、 DSLの仕組みをメンテナンスするコストが見合わない場合が多い中 Poor man's DSL コスパ重視 - 作成者と利用者が同じ人達の場合 - ターゲットが社内のみの場合多リッチなDSL 利用数が多ければクールで気持ちいい書き心地を提供するための労力が報われる - OSSの場合 - 大企業における社内向けライブラリの場合

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyrights(c) Henry, Inc. All rights reserved. 責任を持つ ● 仕組みを作るというのは「制約と誓約」 ○ 縛りを設けることでより力を発揮 ● 制約の中で扱えない概念が現れたときに、土台となる設計をちゃんと見直していけるか ○ 既存の枠組みの中で無理やり対応しようとして余計に複雑になるあるある ● 一定程度安定するまでは関わり続ける（自戒） ● 手離れすることにも責任を持つ（マジ自戒）

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Copyrights(c) Henry, Inc. All rights reserved. （おまけ）ネストした関数リテラルでのスコープ制御 ● DSL関数をネストする場合、祖先のレシーバーにアクセスできてしまう ● `@DslMarker` を使うことで、直近のレシーバーに対してのみアクセスできるように制御するできる ○ ↑のようなコードをコンパイルエラーにできる ○ 詳しくは https://kotlinlang.org/docs/type-safe-builders.html#scope-control-dslmarker

Slide 47

Slide 47 text