抽象度を揃えて書く

特に、上位のレイヤーではpattern maching以外の条件分岐が出現しないようにできると良い

全体的に高めの抽象度に揃えることになる

細かい条件分岐が頻出する部分はdomain logicのレイヤーに押し込める

全体的に低めの抽象度に揃えることになる

例: 比較的上位のレイヤーのコード

例えば、ある機能の仕様が「これとこれと..の5つのステップを踏む」というのがあるとき

5つの関数を並べて呼ぶことでそれを表現できると良い

code:ts

function 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行消せばいい

Viewの場合も同様

ReactのComponentも、Component同士の抽象度を比較して揃えて書く

素のHTMLはComponentに分割できないので可読性が落ちる

例えば、1つのページを表すViewを作り際に、

HTMLでは、1つのファイル内にだらだらと全部を書くが、

Header

Content

Footer

のようなものが並んでいることで、この3つで構成されているということが瞬時にわかる

これたぶんSQLではほぼ不可能なんだよな

他の関数をいくつか呼ぶだけの、宣言的な関数

「要約」を担ってくれる

この関数さえ読めば、だいたい何をやっているかが判別できる

接する層の知識だけで十分になる

public methodの利用者は、多くともpublic methodの中身を見るだけで処理が理解できることが理想

その先にあるロジック関数は見る必要はない

実際の処理を書く

１つだけの処理を実装する

より下の水準のロジック関数を呼び出しても良い

が、複合関数は呼び出さないようにする

usecase層と、repository層では扱っている対象の抽象度が異なる

Entityはアプリケーションから直接アクセスされるべきでないドメインロジックを含むのでより低水準である

repository層, infrastructure層がもっとも低水準であると言える

Entityが必要するような、他のシステムとの接続をやったりするので

主観で判断していると、1つの関数に対する抽象度の評価が各人で異なる可能性がある

それが生じては、あまり意味がない

ある人は「抽象度は揃っている」と言っても、ある人は「抽象度は揃ってない」と言いうる

だとすれば、可読性が上がったとは必ずしも言えない

そのため、この辺のプロトコルを定める必要がある

抽象度を揃えるとは、「その関数内で使用するComputational Effectを統一すること」ではないか？という仮説もある

だからhaskellのような言語では、「抽象度が揃った書き方」が型によって強制される

よってマシなコードが自然に書ける

しかし、Effectが統一されていれば、抽象度が同じになるのか？と言われると、そうでもない気はする

同じIOでも抽象度の異なるものはありそう

仮に「何があっても抽象度を揃えて関数を書きなさい」というルールを強制するとしたら、

そのためには絶対に関数を細かく切っていかないと実現できない

だから「抽象度を揃える」と「関数を小さく作る」の間には何かしらの関係がある

「抽象度を揃える」ために、「関数を小さく作る」べきなのか

前者であって、「どのように小さく作るか」のヒントとして、「抽象度」と考えられる、のか？

そんなことはない？

いや、そもそも「小さく作る」ことは要件ではなくて、「抽象度が揃ってさえいれば良い」のかもしれない

抽象度が揃ってさえいれば、大きかろうが判断できる

というか、自然に大きくならない可能性もある

この辺の話がもし真なのであれば、「関数を小さく作る」や「直交性を保つ」のような確固とした目標に対し、

より具体的な方法として「抽象度を揃える」が使えることになる

そのためには、「抽象度をどう判断するのか」という基準が必要になる

「経験で何となく分かるでしょｗ」ではなく、言語化してみたい

もし偽なのであれば、「抽象度を揃える」の抽象性が高いということ

話は進まないが、別にそういう結論でも良い

SLAPの概要として良い

ただ、どこからどこまでが(出典に基づいた)SLAPの話なのかわからない(重要ではないが)