抽象度を揃えて書く
抽象度の異なるものを一緒に書かない
抽象度を揃えれば、コードの可読性も上がるし、変更も容易になる
特に、上位のレイヤーではpattern maching以外の条件分岐が出現しないようにできると良い
全体的に高めの抽象度に揃えることになる
細かい条件分岐が頻出する部分はdomain logicのレイヤーに押し込める
全体的に低めの抽象度に揃えることになる
例: 比較的上位のレイヤーのコード
例えば、ある機能の仕様が「これとこれと..の5つのステップを踏む」というのがあるとき
5つの関数を並べて呼ぶことでそれを表現できると良い
tsfunction f() {
const a1 = g1();
const a2 = g2(a1)
const a3 = g3()
const a4 = g4(a2, a3)
const a5 = g5(a4)
return a5
}5つのステップや要件があるんだな、ということが瞬時にわかる
機能を追加するときは1行増やせばいいし、不要になったら1行消せばいい
この関数
f の中に細かい条件分岐などを書かないViewの場合も同様
ReactのComponentも、Component同士の抽象度を比較して揃えて書く
素のHTMLはComponentに分割できないので可読性が落ちる
例えば、1つのページを表すViewを作り際に、
HTMLでは、1つのファイル内にだらだらと全部を書くが、
Componentの抽象度合わせることで、
<Page/> の直下にはHeader
Content
Footer
のようなものが並んでいることで、この3つで構成されているということが瞬時にわかる
>#WIP
これたぶんSQLではほぼ不可能なんだよな
だからRepositoryでSQLを実行する関数は、コメントが必要泣きがする
恐らく一般的な単語ではない
たぶん適当にした訳だろうから、元の単語を知りたい #??
他の関数をいくつか呼ぶだけの、宣言的な関数
public methodは複合関数で書くようにする
「要約」を担ってくれる
この関数さえ読めば、だいたい何をやっているかが判別できる
Unixコマンドの1つ1つの使い方さえわかれば、その内部実装がどうなっているのか知る必要がないのと同じ
接する層の知識だけで十分になる
public methodの利用者は、多くともpublic methodの中身を見るだけで処理が理解できることが理想
その先にあるロジック関数は見る必要はない
恐らく一般的な単語ではない
実際の処理を書く
１つだけの処理を実装する
より下の水準のロジック関数を呼び出しても良い
が、複合関数は呼び出さないようにする
Layered Architectureも大域的にこの原則に則っていると言える
usecase層と、repository層では扱っている対象の抽象度が異なる
Entityはアプリケーションから直接アクセスされるべきでないドメインロジックを含むのでより低水準である
repository層, infrastructure層がもっとも低水準であると言える
Entityが必要するような、他のシステムとの接続をやったりするので
適切な抽象度を見極める能力も必要になってくる
主観で判断していると、1つの関数に対する抽象度の評価が各人で異なる可能性がある
それが生じては、あまり意味がない
ある人は「抽象度は揃っている」と言っても、ある人は「抽象度は揃ってない」と言いうる
だとすれば、可読性が上がったとは必ずしも言えない
そのため、この辺のプロトコルを定める必要がある
抽象度を揃えるとは、「その関数内で使用するComputational Effectを統一すること」ではないか？という仮説もある
ほんまかはしらない
だからhaskellのような言語では、「抽象度が揃った書き方」が型によって強制される
よってマシなコードが自然に書ける
しかし、Effectが統一されていれば、抽象度が同じになるのか？と言われると、そうでもない気はする
同じIOでも抽象度の異なるものはありそう
仮に「何があっても抽象度を揃えて関数を書きなさい」というルールを強制するとしたら、
そのためには絶対に関数を細かく切っていかないと実現できない
だから「抽象度を揃える」と「関数を小さく作る」の間には何かしらの関係がある
関数は小さく作ることの嬉しさの一つが「抽象度を揃える」なのか、
「抽象度を揃える」ために、「関数を小さく作る」べきなのか
たぶん前者だと思う
前者であって、「どのように小さく作るか」のヒントとして、「抽象度」と考えられる、のか？
つまり抽象度を揃えれば、直交性が良い感じになる？
そんなことはない？
いや、そもそも「小さく作る」ことは要件ではなくて、「抽象度が揃ってさえいれば良い」のかもしれない
抽象度が揃ってさえいれば、大きかろうが判断できる
というか、自然に大きくならない可能性もある
この辺の話がもし真なのであれば、「関数を小さく作る」や「直交性を保つ」のような確固とした目標に対し、
より具体的な方法として「抽象度を揃える」が使えることになる
そのためには、「抽象度をどう判断するのか」という基準が必要になる
「経験で何となく分かるでしょｗ」ではなく、言語化してみたい
もし偽なのであれば、「抽象度を揃える」の抽象性が高いということ
話は進まないが、別にそういう結論でも良い
SLAPの概要として良い
ただ、どこからどこまでが(出典に基づいた)SLAPの話なのかわからない(重要ではないが)