関数を分割/凝集させる際はデータへの関心でまとめる
@tanakahisateru: 「関数が持つ処理の凝集性を考えるときは、命令の手順まとめだとブレるけど、データへの関心によるまとめだとブレない」←それはそう。で、これはあくまで、関数ひとつの粒度に着目する話。「オブジェクトが持つデータを扱う処理を全て集めてメソッドにしろ」と複数に拡大すると、ファットモデル直行 @tanakahisateru: 関数に何を含んで何を含まないかは、データへの関心かどうかで選別するのがセオリー。そうすると、複雑さを抱えた内部に行差分変更が起きにくくなる。外側は安定度高いそれを扱えばいいだけになって、柔軟にしやすくなる。この「内部に行差分変更」「安定」という見方だと、クラスにメソッド追加は退化 @tanakahisateru: 関数の話だと、データを関心として閉じるのは、単一責任と開放閉鎖の原則に適合するのに、オブジェクトになると、内部データへの関心で処理を集めるのは NG になるの、理解してない人が多い。責任が多重人格になるわ、変更に対して閉じないから拡張を嫌うわで、さんざんになる。 @tanakahisateru: オブジェクト内のメソッド群はな、プロパティを介して全部結合しとるんですわ。与えられたデータだけしか見えてない独立関数とは違うんです。関数で言えばグローバル変数癒着のようなもんです。なので凝集性の閉じはメソッドで考えちゃダメで、オブジェクトが単位なんです。これがわからん人マジ多い @tanakahisateru: 「データを主語に、操作を動詞に」これがオブジェクト指向プログラミングだ、そしてオブジェクト指向は気持ちいいから善なのだ、という、見た目の特徴だけしか合ってない間違ったブランド盲信が広まったのが、諸悪の根源だという闇の深い思想を持っています @tanakahisateru: たぶんなんですが、もともとから主語は、データ実体ではなく、「プロトコルに応える概念」だったはずです。それに Java は、interface という素晴らしい名前を付けました。Go も TS も、構造的部分型だけど、オブジェクトを主語に据えるとき、interface で認識しますよね。型クラスもそんな感じです。