抽象化
抽象化によって得られること
コードを理解しやすくなる
適切に名前がつけられていれば
インターフェースが揃っていれば交換可能
内部実装を気にせずに使える
良いかどうかはさておき
機能の付け外しが簡単に行える
外しが簡単にできるのが着目ポイント
考えられる最もシンプルな状態にしておく
これがYAGNIでもない、最適な「変更にopenな状態」なのかも memo
なんかこういうのテストにも通ずる概念だよなって思うmrsekut.icon
↑「こういうの」は「漏れのある抽象化」を指して言っている
一部のケースだけでなく、未知の事象についても想像して対応しないといけない
既存の複数箇所にあるコードをただまとめるだけの関数切り出しと、未知のものもカバーするような「良い抽象化」はその質が全く異なるよね
最小化
minimalism
インターフェースを通して公開するものを最小化する
詳細を公開しすぎると、クライアントに統合されてしまう
拡張性
extensibility
抽象自体が拡張に開いているように設計する
合成可能性
composability
モジュールとして抽象を設計すると、抽象どうして組み合わせることができる
副作用を持たないように気にかけるなど
下手な抽象化をするぐらいなら、重複したコードを書いたほうが安価という話
下手な抽象化をすると、新しい機能を入れるのが難しくなる
現時点で良い抽象化なら良いが、新しい機能を入れるときに変な分岐が生えるような場合は全ての抽象化をやめてインライン化しろ
無理に分岐で頑張っても後で辛くなるだけ
誰かが頑張って抽象化しても、その後使う人が分岐を生やすことがある
そうするとさらにわかりにくくなる
それをするぐらいなら抽象化せずに個々の場所で書いて重複を許容しろ
既にある抽象化が誰かの手によって分岐が生やされているところに出会ったら、以下の行動をせよ
使用箇所全てにその関数をインライン化する
つまり関数をやめて直書きする
ただインライン化するんじゃなくて、抽象化でない具体化されたコードにして書く
つまり不要な分岐などを含まない
関連
コードの重複を見つけたとき、
そのコードの重複が、「偶然の重複」なのか「本物の重複」なのかを見抜く必要がある 偶然の重複なのであれば、重複すべできではない
ref 『Clean Architecture』.icon p.163
という考え方は、圏論の本質が自然返還であることと関連がありそうmrsekut.icon
関連
UpdaterとSelctorの2つに抽象化する
reducerや、FCもこの2つで表現できる
参考