クリーンアーキテクチャ 7章～9章

第3部 設計の原則

• SOLID 原則
  • 関数やデータ構造をどのようにクラスに組み込むのか、相互接続をどのようにすればいいのかの指針
• SOLID 原則の目的
  • 変更に強いこと
    • 変更に弱くても、コードの可読性さえ担保してくれたらどうにでもなる
  • 理解しやすいこと
    • 絶対大事。理解が難しいと、変更も難しい一体何をしているのかどうかも意味不明になる。一番重要。
  • コンポーネントの基盤として、多くのソフトウェアシステムで利用できること
    • そうなんだけど、Unity の現場における多くのソフトウェアシステムで利用できることがほとんどないような・・・(事故るところをたくさん見てきたため)

第7章 SRP: 単一責任の原則

モジュールを変更する理由はたったひとつだけであるべきである

• 給与システム Employee クラスがあるとする。その中で calculatePay、reportHours、save の3つのメソッドが存在する
  
  • うん、これはだめですね Employee が神クラスになっていて、何でもやりすぎ感
• 使用用途が様々な場所のものになる場合はコードは分割するべきという原則
  • 一度やらかした記憶が・・・遠い昔なのでいつだったか覚えていないが
• マージするときにコンフリクト起こして大変なことになる
  • それはそう

第8章 OCP: オープン・クローズドの原則

• コンポーネントはすべて一方通行にすべき
  • 一方通行じゃなくて両参照もいっぱい見てきたけど、そらもう大悲惨
• OCPの目的は、変更の影響を受けずにシステムを拡張しやすくすること
• 上位レベルのコンポーネントが下位レベルのコンポーネントの変更の影響を受けないことにすること

第9章 LSP: リスコフの置換原則

• オブジェクト指向の黎明期には継承の使い方の指針になるものだと考えられていたっぽい
• 現在はインターフェイスと実装に関するソフトウェア設計の原作
• const 定義しないでハードコーディングはやばいって・・・
• 置換可能性に違反してしまうと、システムが特別な仕組みだらけになる
  • そのプロジェクトでしか使えないものになるとかたまによくあるよね