2023/7/4 公開するものを減らすのと、責務が異なるので分割すべきでしょの塩梅が難しい
大事だが、上辺っちゃ上辺、みたいな
その前段階に概念モデル化があり、その時点で抽象化にミスってるとどうしようもない(?) というか、一致させる必要がない、と言ったほうが正しいか
論理的なmoduleに合わせすぎると早すぎる最適化にもなりえそう
ここの判断とか
間違いやすいし、間違ってることに気づきづらい(?)
そういう意味だと、論理的には同じmoduleだが、実際に実装してLCOMを測ったら高すぎワロタ、という状況も有り得そう 問題は、その時に、じゃあmoduleを分けましょう、と即座に判断して良いものなのか
今考えている対象が、論理的なのか物理的なのか、というのは意識したほうが良さそう
各機能の責務とレイヤーを規定したい
依存の対象をどこで見るか?という話にも繋がる
引数で見えることと、importで見えることの違いはなにか?
immutableなことが前提
global変数ってなんで悪なんだっけ?
DI Containerって何を解決してるんだっけ
Application Monadの意義って何だっけ
もっと具体的な例
tailwind のstyleを変数で定義しましたinputStyle
これを子のComponentに適用する際に、propsで渡すことと、importして渡すことの違いってなんだっけ
依存の方向が若干異なるな
親の中でinputStyleを定義してexportすると
Component自体は親→子なのに
style部分だけ親←子になってしまう
「親がレイアウトを決める」ということ自体は同じなのに、依存方向が変わる
マイクロサービスも同じノリ?
その上で、各ファイル、moduleの責務を考える
同じものは近くに置く
1つのファイル内にまとめるのか、1つのファイルは1つの責務を持つようにするのか
ここで、関数やclassの凝集度がどうのこうのという話をするなら、directoryに関しても同じ理由でそうすべきだよね、となる
つまり、PBF的なディレクトリ構造が自然に採用される
凝集度のような概念は良く知られているのにPBLが採用されている事が多いのはなぜだろう
↑この観測がミスってる可能性
凝集度の話と、ディレクトリ構造の概念を別物として捉えられている可能性
抽象化できていない
PBLの方が、レイヤーごとに凝集できてて偉い、と思っている可能性
個々の関数やclassに対するあるあるgood code案件は全く同じままディレクトリなどにも適用できる
脱線するけど、1つのcommitやPRの中で1つのことをする、という責務の話も
コードだけでなく、他のものに展開できる
別ファイルなどに分けるということは完全にinterfaceのみでやりとりするということ
AがBの内部に依存しているような構成になってるなら、
それでいてかつBがAでしか使われていないならわざわざファイルを分ける必要がない?
いややっぱ順番逆かもなmrsekut.icon
そもそも最初に分節した後にレイヤーを作っても問題ない
そのpackageに閉じてるなら何をやっても良い
その次に公開範囲を考える
公開範囲に関しては、ツールの問題という気もする
だから、考えても仕方ないというか、考える価値がそこまでないというか
「公開範囲がどこからどこまで」というのが機械的に制限できる仕組みが入っていれば良い
コンパイラやリンターレベルでチェックできれば良いが、
最悪、importのpathを見た人間が判断するルールでも良い
レイヤーのルールがちゃんと定まっていれば、公開範囲はどうでも良い
公開範囲が問題になるのは、「ここはカプセル化してるつもりだったので、外部からは使わないでください」といった問題を避けるため
レイヤーのルールを徹底できてるなら、全部をpublicにしてようとも全く問題にならない
単に、人間が見たときに意図が伝わるかどうかぐらいの問題しかない
「publicって書いてるのにどこからも使ってないじゃん!」という問題が起きるぐらい
実際これは問題なのだが、「レイヤーのルール」の方を先に考えるべきで、ここはあとから二次的にどうにかすれば良い
公開範囲はどちら側から規定できるものなのだろうか
公開側のmodule?
一般的にはこっち
exportと書けば公開される
interfaceをちゃんと考えた上で必要なものだけを公開する
ファイル内でもそうだし、ディレクトリ単位でもそう
これはmoduleの外まで公開しますよ、というのを実装時に結論を出す
import側?
importのpathを見て、これは別moduleすぎるからimportすべきでないと考える
前者かなさすがに
import文から依存関係を解析
これもレイヤーやmoduleの分け方が定まっているのが前提
その後に考えれば良い
し、たぶんその前提がちゃんとしてるなら、自動的に良くなる気がする
テスト戦略
これもレイヤー以後の話
「publicなもののみをテストすべき」みたいなやつも、どこのレイヤーまでをpublicとみなすか、という話になるだろう
↓を↑に分割しながら移動して、
その後、適度にページを分けようmrsekut.icon
もはやタイトルともズレてるのでどうにかしたい
↓殴り書き
カプセル化の観点で考えれば、
1ファイルの中につらつら書いて、
一番上に定義してあるメインの関数のみを公開すれば、利用者はその内部を知らなくて済む
しかし、これを突き詰めすぎると、1つのファイル内に、雑多なものが置かれることにもなる
極論いえば、アプリケーションの全てを1ファイル内に書けば、main関数1つのみ公開することもできる
責務が異なるのでファイルを分割すべき
ファイルツリーを見ることで、何が存在するのかわかる
しかし、そうすると、一部のpackage向けに書いた関数なのにglobalに公開しちゃうのか〜、という気持ちにもなる
これは言語のmoduleシステムがヘボすぎ、というのもある
最近、べらぼうにpublicにすることに謎の抵抗感があって、ファイルがやや大きくなりがちな感じがある
テストの観点
publicのテストとか
この辺か