内部の計算はアプリケーションの入力のことを知らなくて良い

↓にタイトルなんかないんだよな

例えば、以下のような例を考える

以下のような直角三角形の面積Sを求めるような状況を想定する

ここで、AとBをユーザに入力させ、最終的に面積Sを得たい

https://gyazo.com/176acaeb5565fe140a4ea910ffe87763

この時、Sを求める関数の引数は2通り考えられる

Cを仲介するもの

code:hs

calcC :: A -> B -> C

calcS1 :: A -> C -> S

入力から直接Sを得るもの

code:hs

calcS2 :: A -> B -> S

calcS2 a b = calcS1 a (calcC a b)

上記の例でいうと、

「直角三角形の面積の求め方は？」と問われた時に、真っ先に思いつくのが「1/2 * A * C」と、なるような状況を想定している

これでいてかつ、更に引数が多いような状況で、どういう設計にするか？というのを考える

当然Cを仲介するべき、という結論は恐らく正しい

ただ、気になるのは、calcCの配置場所、だろうか？

何に悩んでるんだっけ..

例が恣意的すぎて逆にわからなくなってきたな

calcS2の配置場所か

calcS2を作ると前提した時に、calcS2の配置場所に悩んでたということかな

calcS2をそもそも作らない、という結論でいけそうでは

calcCに依存する処理が増えてしまう

calcS2を作ればwrapすることで直接calcCに依存することを減らせるが？

依存や知識という面で観察する

内側から見た時

「Sを求める関数」は、「AとCから計算される」ということだけを知っていれば良い

ボトムアップに考えるなら自然にそうなる

「このアプリケーションの入力はAとBである」ということを知っている必要はない

Viewに依存させてはいけない

境界を作る話と同じ話をしている気もする

calcS2のようなものを作ると、直接的にSに依存する物の数が増える

そこでCという概念を仲介させることで、Sに依存する物の数を減らせる

敢えてトップダウンに説明するならこうなるか

利用者の煩わしさの具合はいかほどか

単純に見れば、わざわざCを仲介しないほうが、呼ぶ関数が少なくて便利、と思えてしまう

Sを求めたい場所が複数に散らばった時に、毎度Cを仲介するのが面倒？