クリーンアーキテクチャ 12章～14章

第4部 : コンポーネントの原則

• - ソフトウェアコンポーネントの構成要素と、どのように組み合わせて作っていくかという内容になっているよう

12章 : コンポーネント

• 昔はメモリアロケートしたらリロケートできなかった
  • まぁギッチギチに実装したら、自分でメモリ確保してポインタ持っておいて、そのメモリ上にいろいろデータ突っ込みたいよね
    • PS3 のアーキテクチャもそうだったよね
    • サブCPU (名前忘れた)は必ず64KByte に収めるとかなんかいろいろルールがあったようななかったような
  • 機械のスペックが上がっていったので、メモリはほぼ確認しなくてもすむ環境「には」なっている。ただゲームとなると話は別・・・
• マイクラの MOD が作りたかったら、特定のフォルダに自作.jarを配置すればいいよね
  • この自作.jar も1つのコンポーネント事例
  • ここらへんは海外の Mod 文化にかなり影響を与えていそう 
• 全体的に昔の環境とその解決策を書いていた歴史みたいなのが書いていた

13章 : コンポーネントの凝縮性

• 再利用・リリース等価の原則(REP)
  • コンポーネントはクラスやモジュールを適当に寄せ集めるものではなく、一貫するテーマや目的を集めべき
    • まぁなにも関係ないコードが入っているとすごいムカつくよね(実体験)
• 閉鎖性共通の原則(CCP)
  • 単一責任の原則(SRP)は、クラスを変更する理由が複数あるべきではない
  • 閉鎖性共通の原則は、コンポーネントを変更する理由が複数あるべきではない
    • コンポーネントとクラスの違いってなんだっけ・・・
      • コンポーネントは Unity+C# で言えば asmdef で dll 切り分けするようなものか
  • 多くのアプリケーションでは、再利用性より保守性が重要。1つのコンポーネントに変更箇所がまとまってくれていたほうがとてもありがたい。
    
    • わかる
    • ただし、何をやっているのかよくわからないものまで巻き込まれてしまうと、変更箇所まとまりすぎても頭を抱えてしまうときがある。まずそうだったら同じコンポーネントを別でつくってしまうときも
      • まぁこれは単一責任の原則で分割する手もあり
• 全再利用の原則(CRP)
  • 一緒に用いられることが多いクラスやモジュールは、同じコンポーネントにまとめよ
  • 不要なものには依存しない
    • たまによくあるやつだ。クラス作って new されているのはわかってるけど、new した先はまじで何もしていないものとか

14章 : コンポーネントの結合

• 非循環依存関係の原則(ADP)
  • asmdef 切っていると循環参照できなくなるからいいよね
  • Unity だと FindObjectOfType で相互参照しまくっているプロジェクトをよく見てしまっているので、これを簡単にやられないよう注視する必要がある
    • それがコードレビュー
• それを解消するために、Interface を切ってクラスごと渡したりする
  • まぁやりたい放題はできるよね