汎用的・具体的な構造に対する操作を分ける

あらゆる関数は以下の2つに分類できる？

操作に重点を当てたもの

具体的なデータ構造視点で導かれる

上記の関数を使用する層

例えば

具体的なデータ構造を、汎用的なデータ構造に変換するとか

型クラスのinstance定義時の実装とか

任意のgetterとか

main関数とか

できるだけ、ドメイン固有の値を知らないパーツを増やす?

また、上記の2つを分離する

この観点で見れば、entityとfeatureも分かれるイメージが付く

entityという具体的な構造に対する操作

entityの構造に依存する

できるだけ減らす

feature

汎用的な構造に依存するようにする

具体的なドメインのデータ構造を知らない

命名もできるだけそれを意識する

やりすぎると意味わからんくなるので無理しなくて良い

パターンを提供する感じ

極論を言えば、別のプロダクトにもそのまま持っていける

entityに直交するように用意する感じ

できるだけこっちの量を増やす

本当は全部こっちで書きたいが無理なので泣く泣く前者も用意する感じ

このようにこう考えると

directoryの作り方としては、

Package by Module(?)的なものがあると良いといえる

「Package by Module」は名前として情報量がないのでもっと良い命名があるはず

イメージとしては、

ビジネスに強く根付いた構造は、機能として表現すれば良くて、

それとは別に、汎用的な構造を扱うものをpackagingしたツール集を用意する

PBFするときにcomponents/というディレクトリが必要になるのと似ている

データ構造はまあ仕方なく具体的にし、

操作をできる限り汎用にする？

この操作って別の対象にも使えるなとか、

このパターンを適用できるなと言ったことを考える？

それがいわゆるInterfaceというやつ

methodの、名前と型だけ決めて実装はないやつ

上部の関数の工夫も考えていきたい

下層の方は徐々に解像度が上がってきた

上層、メイン関数近くの関数についても考えたい

ここは、具体的なデータ構造を、汎用的な関数に流し込むところ

具体的なデータ構造を知識を持ってしまい、どうしても混雑しがち

混雑している部分が一部にまとまってるんだから良い、と諦めるのか、

更にもっと工夫できそう、というのを見つけるか

A←B←C←D のような依存関係で計算できるものがあった時、

code:_

:: A → D

calcDFromA = calcD . calcC. calcB

のようにできると良い

1つ1つの関数が汎用性がある

それはさておき、calcDFromAの方の命名に困る

ユーザの直接の入力から、深いものを求める感じの関数

特に引数が複数ある場合にどうするんじゃい、というのがある

いま具体的に特定のgetterで困ってる

特定の目的に強く依存しているというニュアンス

大きい関数から、何も考えずに部分を抜き出しただけ、みたいなやつ

恣意的すぎる、具体的すぎる

汎用性がない、変更に弱い

interfaceの考慮不足

「詳細を知っている」ってそういうことか

isHogeみたいなやつとか

UI機能も同じや

恣意的すぎる機能

とはいえ、抽象化しまくれば良いというわけでもない

一言で言えば、interfaceはトップダウンに考えろってことか

と言うより、interfaceをボトムアップで考えるな、ってことかも

記憶を消す必要がある

具体的な使用方法から抽象を考え直す必要がある