ちょっとしたオレオレDSLも抽象構文木っぽくしておくと後からの拡張に対応しやすいよねっていうちょっとしたお話

ちょっとしたオレオレDSLも
抽象構文木っぽくしておくと
後からの拡張に対応しやすいよねっていう
ちょっとしたお話
2017/02/21
和田潤也

Copyright © 2014 Sansan, Inc. All rights reserved.
> 自己紹介
Sansan事業部開発部
和田潤也
@chocolamint
某 SIer で Web 系のフロントエンド寄り基盤の開発をメインに従事
2015年12月よりに JOIN
• 壁を登ってた時代がありました……
• 最近の週末は女性声優のイベントで忙しいとのこと

> オレオレDSLってなんのこと？
田中太郎 OR 次郎
田中太郎次郎ORAND

> 実際にあった事例
- https://github.com/eightcard/lk-linkknowledge/pull/6781
public class Token
{
public TokenType Type { get; }
public IList<string> Words { get; }
public Token(TokenType type, IList<string> words)
{
Type = type;
Words = words;
}
}
public enum TokenType
{
AndAlso,
OrElse
}
むむむ？

> なるほど、こういう想定
AndAlso
["田中"]
OrElse
["太郎", "次郎"]
パーサーが
IEnumerable<Token> を返す

> データ構造の修正はコストがデカい
括弧で優先順位をつけられるようになったら？
田中 OR (山田太郎)
引用符で「完全一致」が指定できるようになったら？
"田中太郎"

> 本来の構造に忠実にいこう
あお
いうえ
AND
OR
MultinaryExpression
多項式
LiteralExpression
リテラル式

> データ構造に落としてみました

> ついでに Visitor パターン使ってみました

> なおパーサーは愚直な模様
「パーサーコンビネーター」とか
言ってみたい

> YAGNI≠拡張性への考慮を捨てる
You ain't gonna need it
「作らない」⇒ あとから作れるように！

> 「拡張しやすい」とは何なのか

> 現実に即しておく＝シンプル
• 現実のモデルとの差異を埋める必要がない
• 現実との乖離から生じるリスクが少ない
• 現実的に起こり得る将来の変更に対応しやすい

> もう一つの例
SQS
IThrottlingPolicy

> 同時実行するメッセージの数を制限する
interface IThrottlingPolicy
{
Task<IDisposable> EnterAsync(
CancellationToken cancellationToken);
}
• SemaphoreThrottle で単純な上限数制御
• IntervalThrottle でスループット制御

> とりあえず差し込めるようにしておく？
- ✓ DO provide at least one type that is an
implementation of an interface.
https://msdn.microsoft.com/ja-jp/library/ms229022(v=vs.110).aspx
理想的には 2 つ以上作ってみるのがオススメ
（実利用するかはともかく脳内で）
適切に抽象化できていれば
複数の実装が提供され得るはず

> 設計が全て
- そのインターフェースは何故必要ですか？
- 「あってもなくてもいい」インターフェースは要らない
- そのインターフェースは何をしますか？
- 明確な 1 つの責務を持つべき
- そのインターフェースにはどのような実装が想定されますか？
- 実装が 1 つしか考えられないインターフェースは要らない

> 必要になったら作れるようにしておく
- 最初の検索の例
- パーサーは括弧を想定していない状態
> なので入れ子構造の式ツリーは返ってこない
- パーサーが対応されれば Visitor は勝手に対応される
- ○○が起こったタイミングで△△する
- Publisher は○○が起こったことを知らせる
- Subscriber は通知を受けて△△をする
- ☆☆というルールで■■をする
- ■■をする方法（戦略）は☆☆以外にも考えられる

> ソースはシンプルに・想定は複雑に
- いま「やりたいこと」は何か
- 将来変わらない「やりたいこと」は何か

> どちらがシンプルか
メッセージを同時に4つずつしか取り出さないように
制御しながら、順次取り出して処理する
メッセージを
順次取り出して処理する
同時に4つずつまでしか
取り出さないように
制御する

> Make it simple

ちょっとしたオレオレDSLも抽象構文木っぽくしておくと後からの拡張に対応しやすいよねっていうちょっとしたお話

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ちょっとしたオレオレDSLも抽象構文木っぽくしておくと後からの拡張に対応しやすいよねっていうちょっとしたお話

Similaire à ちょっとしたオレオレDSLも抽象構文木っぽくしておくと後からの拡張に対応しやすいよねっていうちょっとしたお話 (20)

ちょっとしたオレオレDSLも抽象構文木っぽくしておくと後からの拡張に対応しやすいよねっていうちょっとしたお話