Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Unity開発で使える設計の話+Zenjectの紹介

31,213 views

Published on

プログラマのためのUnity勉強会
http://peatix.com/event/311392

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Unity開発で使える設計の話+Zenjectの紹介

  1. 1. Unity開発で使える設計の話 + Zenjectの紹介 2017/11/26 @toRisouP
  2. 2. 自己紹介 • 名前 とりすーぷ(@toRisouP) • Qiitaとかよく書いてる • 同人ゲーム作ってる
  3. 3. ハクレイフリーマーケット • 2017年10月にリリースした東方二次創作ゲーム • オンライン対戦対応のパーティゲーム
  4. 4. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か • まとめ
  5. 5. 設計とは何か
  6. 6. 設計とは何か • 何をどうやって作るのかを決定する作業 – そもそも何を作ろうとしているのか? – 必要な機能はどうすれば作れるのか? – 必要なリソースは何なのか? – 作るのにどれくらい時間がかかるのか? – どういう手順で作業をするのか?
  7. 7. だいたいの開発フロー 1. 企画を決める 2. 仕様を決める 3. システム設計する 4. コーディングする 5. テスト、デバッグする 6. リリースする 7. 運用、保守する ←ここ
  8. 8. 設計すると何がよいのか?
  9. 9. 設計のよさ • 設計することで作るものの全体像が可視化される – 規模感をチーム内で共有できる – 何から手を付ければ効率よく進むかわかるようになる – 今後問題が起きそうな部分を先に洗い出せる
  10. 10. 本題
  11. 11. モデリングとクラス設計
  12. 12. モデリングとクラス設計 • モデリング – 抽象的な考えを図や記号で可視化する作業 – 3Dモデリングの意味ではない – UML(統一モデリング言語)を使って描くことがほとんどである • クラス設計 – どういうクラスを作るのか クラス同士がどういう関係であるのか、 といった具体的に何のクラスを作るのかを決める作業
  13. 13. モデリングの例
  14. 14. モデリングの例:シーケンス図 • オブジェクト同士のやりとりを時間軸に沿って表現する図 – 複雑な処理を可視化することができる – 通信処理が挟まる部分などはシーケンス図を作っておくと混乱しない
  15. 15. モデリングの例:アクティビティ図 • 手続きの流れを表現する図 – フローチャートの上位互換みたいなもの – 状態遷移図に似てる(似てるだけで別物である)
  16. 16. モデリングの例:クラス図 • 登場するオブジェクトとその関係性を表す図 – クラスやインターフェイスなどのオブジェクトを記載 – 関連・依存・集約・コンポジション・汎化・実現なのどの 関係を矢印で表す
  17. 17. モデリングをやるメリット • これからの作業内容を可視化できる – どこから作れば効率がよいかわかるようになる – 実装時に迷うことがなくなってスムーズに開発できる • 後から見返す時の資料として残すことができる – どういう作りになってるか俯瞰的に見ることができる – 不具合調査時のあたりがつけやすい – 引き継ぎや新人教育に使える
  18. 18. クラス設計
  19. 19. クラス設計 • クラスの関係をモデリングすること – どういうオブジェクトが必要なのか – オブジェクト間がどういう関係にあるのか?
  20. 20. クラス設計は適当にやれば OKといったものではない
  21. 21. クラス設計をやるためには • クラス図が読み書きできる必要がある – UMLのクラス図を覚えるのがよい • 設計原則を覚える必要がある – 設計する上で守ることが推奨されるルール • 設計の定石も覚えておくべき – デザインパターンやDIといった応用性の高い考え
  22. 22. こういった クラス設計をする上で 覚えておくべき知識を解説します
  23. 23. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か – かんたんな使い方 • まとめ
  24. 24. (クラス設計をやる上で) 覚えておくべき基礎知識
  25. 25. 覚えておくべき知識 • クラス図の読み方 • SOLID原則 • デザインパターン
  26. 26. クラス図の読み方
  27. 27. クラス図の読み方 1/6 • オブジェクトの読み方 – 名前空間、各記号の意味 名前空間 abstract class interface class struct
  28. 28. クラス図の読み方 2/6 • オブジェクトの読み方 – アクセス修飾子、フィールド、メソッド定義 ○ Public ◇ Protected □ Private フィールド メソッド
  29. 29. クラス図の読み方 3/6 • 関連 – 実線で繋ぐとつながりを示す – 実線矢印で繋ぐと一方通行の関連を示す (「使う側 → 使われる側」という向きで引く) PlayerとItemは 相互に関係がある WeaponはBulletを知ってる BulletはWeaponを知らない
  30. 30. クラス図の読み方 4/6 • 依存 – 破線矢印:片方が相手の状態に対して影響を受ける • 例)麻痺状態になるとすばやさが1/4になる
  31. 31. クラス図の読み方 5/6 • 集約、コンポジション – それぞれ「本体とパーツの関係」を表す • ◇が集約:分解できる関係 • ◆がコンポジション:分解できない関係 – 数字を書くと個数を表す 集約 コンポジション
  32. 32. クラス図の読み方 6/6 • 汎化 – 白抜き実線矢印:クラスの継承関係を表す • 実現 – 白抜き破線矢印:インターフェイスの実装を表す BossはEnemyを 継承している Blockは IBreakableを 実装している
  33. 33. 読み方はわかった
  34. 34. じゃあ描く時は?
  35. 35. PlantUMLを使うことをおすすめ • テキストベースでUML図が描けるスグレモノ – クラス図の他にシーケンス図やアクティビティ図も描ける – AtomやVS Codeにプラグインを入れればすぐ使える
  36. 36. 覚えておくべき知識 • クラス図の読み方 • SOLID原則 • デザインパターン
  37. 37. SOLID原則
  38. 38. SOLID原則 • オブジェクト指向プログラミングにおける5つの原則 – 「原則」の名の通り、理由があって違反するのは問題はない • SOLID原則を意識すれば設計はだいたいは上手くいく – Unity開発でも当然SOLID原則は有効 • 普通はオブジェクト指向で開発するしね?
  39. 39. 5つの原則 • 単一責任原則 – Single Responsibility Principle • オープン・クローズド原則 (重要) – Open-Closed Principle • リスコフの置換原則 – Liskov Substitution Principle • 依存性逆転の原則 (重要) – Dependency Inversion Principle • インターフェイス分離の原則 – Interface Segregation Principle
  40. 40. 単一責任原則 Single Responsibility Principle
  41. 41. 単一責任原則 「1個のクラスに役割は1つ」 • 1つのクラスを変更する理由は1つでないといけない – 1個のクラスに複数の仕事を持たせてはいけない • クラスの名前を適切につけるのがコツ
  42. 42. 例:単一責任原則に違反したクラス • PlayerControllerクラス – キー入力管理 – 移動 – アニメーション再生 – 体力管理 – エフェクト・効果音再生 1つのクラスに機能が詰まりすぎ! 機能追加や修正する時に、関係ない部分に影響が出る可能性が高い!
  43. 43. 単一責任原則を守ったクラス 役割に応じてクラスを分割しよう! 名前を見たら何をするのかすぐわかるくらいの粒度が適切 • 移動管理:PlayerMover • 入力管理:PlayerKeyInput • アニメーション:PlayerAnimator • エフェクト再生:PlayerEffectPlayer
  44. 44. オープン・クローズド原則 Open-Closed Principle 重要
  45. 45. オープン・クローズド原則 モジュールは 拡張について開いていなければならず、 修正に対して閉じていなければならない
  46. 46. どういう意味? • 機能の追加は簡単にできないといけない(オープン) • ただしその時に修正が発生してはいけない(クローズ)
  47. 47. 要するに? • 基底クラスやインターフェイスを使って、 抽象的に操作できるようにしよう
  48. 48. よくない例 • Bulletクラスが相手に対してダメージを与えるコード – Tagを見てswitch文で処理を分岐している
  49. 49. 何がダメ? • Bulletの操作対象が増えた時にコードに修正が必要 – 全てのSwitch文を漏れなく探して書き換える必要がある – 変更の手間もかかるし、修正漏れがあっても気づけない Bossを実装したのでSwitch文に追加 もし追加を忘れてもエラーにならないし動いてしまう
  50. 50. どうすればいいのか? • 処理を「抽象」に依存させればよい – 基底クラスやインターフェイスを使って処理を呼び出す実装に変える • こうするとSwtich文は不要になる
  51. 51. オープン・クローズド原則 • インターフェイスや基底クラスで抽象化しよう – 使う側が相手の型を意識する実装は不健全である – 機能を追加する時は「継承」や「実装」を行えばよい – 既存コードの変更は一切不要になる • GetComponet<T>はインターフェイスも指定できる – 指定インターフェイスを実装したコンポーネントを取得できる – 相手が何のオブジェクトか意識せずに処理を書くことができる
  52. 52. リスコフの置換原則 Liskov Substitution Principle
  53. 53. リスコフの置換原則(LSP) 派生型はその基底型と 置換可能でなければいけない
  54. 54. どういう意味? • 派生型は基底型で決めたルールを変更してはいけない – アクセス修飾子を派生で勝手に上書きしてはいけない – メソッドを実行するのに必要な判定を基底より強化してはいけない – メソッドの実行結果を基底より緩くしてはいけない
  55. 55. LSP違反すると何が起きるのか? • 型安全性がこわれる – 間違えた使い方をしてもコンパイルエラーにならない – 実際に動かすまで正しく動作するかわからない • 「型」を意識してコードを書く必要が出て来る – ある型の時のみ処理を分岐する、みたいな処理が出て来る – オープン・クローズド原則に違反する
  56. 56. LSPを違反させる例 • IDをもつ「Enemyクラス」 – IDが同じならば同一の敵であると判定する
  57. 57. 同一性のチェック • IDが同じならtrue • IDが違ってたらfalse • この場合は正しく動く!
  58. 58. LSP違反クラス • 「EnemyWithTeamIdクラス」 – IDとTeamIDの2つを使って同一性チェック – 基底のIsSameEnemyをnewで隠蔽している
  59. 59. 同じクラス同士で比較すると… • ちゃんと判定できる – Idが同じでもTeamIdが違うのでfalse判定になる
  60. 60. これをEnemyにアップキャストすると… • 判定が壊れる – 両者でIsSameEnemyの挙動が違うのだからあたりまえ – “EnemyWithTeamId”を”Enemy”として扱うと危険になってしまった
  61. 61. リスコフの置換原則 • 基底クラスの定めたルールには従うこと – 派生クラスで勝手にルールを書き換えると動作保証できなくなる – is-aの関係を破壊するような継承を行うと違反しやすい – Equalsのoverrideも違反しやすいので注意 • C#のnew修飾子はLSP違反を引き起こす可能性が高い – newでメソッドを隠蔽すると基底と派生でふるまいが変わってしまう – メソッドを上書きする場合はできるだけvirtual・override修飾子を使おう
  62. 62. 依存性逆転の原則 Dependency Inversion Principle 重要
  63. 63. 依存性逆転の原則(DIP) 上位モジュールが下位モジュールに依存してはいけない どちらも抽象に依存するべきである
  64. 64. つまり? • 上位モジュールが仕様を決め、 下位モジュールがその仕様に従うのが正しい姿である – 上位モジュール:相手を使う側のクラス – 下位モジュール:上位から使われる側のクラス 下位 上位
  65. 65. だめな例 • 上位モジュール:Player • 下位モジュール:Enemy • PlayerがEnemyに対してApplyDamageを実行する
  66. 66. 下位モジュールを変更する 「Enemyの種類が追加された」 「ApplyDamage()の仕様を一部勝手に書き換えた」 ↑ 増えた ↑ 引数が増えた
  67. 67. 上位に変更が必要になる • PlayerはApplyDamage()の呼び出しを全部書き換える必要がある – シグネチャが変わったことに対応しないといけない – Enemy2が増えたことで処理の分岐も必要になる – オープン・クローズド原則にも違反している
  68. 68. 修正:依存関係を逆転させる • インターフェイスをPlayer側に定義してそれを使う – インターフェイスの管轄をPlayer側にするのがキモ – EnemyにPlayerの仕様を押し付けることができるようになる
  69. 69. 依存関係の「逆転」 • 矢印の向きがちゃんと逆になってる
  70. 70. 適用できる場所の例 • クラス内で他のクラスを直接newしている → 他のClientに差し替えようとするとコードの修正が必要になる
  71. 71. 依存性逆転をすると • 依存するインスタンスを切り替えられるようになる – 用途に合わせてClientを差し替えられる
  72. 72. 他にも… • Singletonへの依存を弱めることができる – UnityだとManagerクラスをSingletonで作ることが多い – 利用するManagerを外から渡してあげるようにすれば、 Singletonへの依存が消せるようになる
  73. 73. 依存性逆転の原則 • 依存関係をインターフェイスを使って整理しよう – 上位が仕様を決め、下位がそれに従うのが正しい設計 • インターフェイスの使い所はここ! – インターフェイスは依存性逆転を行うためにある(と思う) • 「依存性注入」への話にもつながる – 詳しくは後述
  74. 74. インターフェイス分離の原則 Interface Segregation Principle
  75. 75. インターフェイス分離の原則 クライアントが利用しないメソッドへの依存を 強制してはいけない
  76. 76. 意味 • インターフェイスは適切な粒度で定義しよう – 不必要なメソッドがインターフェイスに紛れていると 使う側で混乱する – インターフェイスを適切に分離し、 必要なインターフェイスにだけアクセスできるようにしよう
  77. 77. SOLID原則のまとめ • SOLID原則はクラス設計の中核 – これをちゃんと守っていれば設計はだいたいなんとかなる • SOLID原則は絶対ではない – あくまで「原則」 – あえて違反したほうが逆にキレイにまとまるんであれば、 違反してもよい(柔軟に対応しよう)
  78. 78. 特に • オープン・クローズド原則 • 依存性逆転の原則 • この2つは特に重要で、ここをしっかり意識すると かなりまともな設計ができる
  79. 79. 覚えておくべき知識 • クラス図の読み方 • SOLID原則 • デザインパターン
  80. 80. デザインパターン
  81. 81. デザインパターン • プログラムにおける設計の定石 – こういう時はこの設計にするといいよ、というパターン集 • GoFデザインパターンが特に有名 – 23個の汎用パターン – 他にもMVCやMVVMやMVPといったアーキテクチャに関する デザインパターンもある
  82. 82. GoFデザインパターン一覧 • Iterator • Adapter • TemplateMethod • FactoryMethod • Singleton • Prototype • Builder • AbstractFactory • Bridge • Strategy • Composite • Decorator • Visitor • ChainOfResponsibility • Facade • Mediator • Observer • Memento • State • Flyweight • Proxy • Command • Iterpreter
  83. 83. 個人的によく使うGoFのパターン • GoFのデザインパターン – Observerパターン – Mementoパターン – Facadeパターン
  84. 84. Observerパターン • イベントの通知と購読を実現するパターン • 観察者(Observer)と観察対象(Subject)が登場する • 「Rx」はObserverパターンをベースに作られている – UniRxを使っている人は自然にこのパターンを使っているはず
  85. 85. Mementoパターン • Undo機能を実現するパターン – インスタンスの状態を別の場所に保存しておくことで、 特定のタイミングでインスタンスの状態を巻き戻せるようになるパターン • パズルゲームで1手前の状態に戻す • プレイヤが死んだらプレイヤのステータスを開始時点に戻す • などといった場面に使える
  86. 86. Facadeパターン • 処理を簡単化する窓口を提供するパターン – GameObjectにたくさんのコンポーネントが張り付いていて、 どこから欲しい情報を集めたら良いのかわからない! みたいな時に、処理を一括して受け付ける窓口を提供する
  87. 87. 例 • Playerから情報を取得したい – 今ダッシュしているのか? – 今空中にいるのか? – 気絶しているのか? – 何のアニメーションを再生しているのか? • どのコンポーネントから情報を取り出せば いいんだ?
  88. 88. Facadeオブジェクトを作る • PlayerDataProvider – プレイヤの情報を収集して外に返す窓口クラス
  89. 89. 外からの情報取得が簡単になる • PlayerDataProviderさえ取得すれば情報が取れる – PlayerDataProviderが代表してデータの収集をする – 内部の構造がどうなっているか外から気にしなくて済む – 複雑なシステムを外からは簡単に触れる用にしたい時に Facadeパターンは有効
  90. 90. デザインパターンのまとめ • 設計作業の指針にできる – 何かのデザインパターンに当てはめると簡単に実装できたってこともある – チームでコミュニケーションを取る時に、デザインパターンの名前がスッと 出てくると話が早い • ただしデザインパターンに振り回されてはいけない – メリットもあるが、デメリットもあるパターンが存在する – デザインパターンを妄信せず、自分で考えてアレンジする必要がある
  91. 91. 覚えておくべき知識・まとめ • クラス図の読み方、描き方 – クラス図を読めるようになるとよい – 描く時はPlantUMLを使うのがおすすめ • SOLID原則 – 特にオープン・クローズド原則と依存性逆転の原則が 個人的に重要だと思う • デザインパターン – 覚えておくとよい
  92. 92. 以上が設計のお話
  93. 93. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か • まとめ
  94. 94. Zenject
  95. 95. Zenjectとは • 依存性注入を管理してくれるフレームワーク – AssetStoreから無料でDLできる(MITライセンス) – 最近は採用事例が増えてきた
  96. 96. Zenjectを知るにはまず 依存性注入の理解が必要
  97. 97. 依存性注入 Dependency Injection
  98. 98. 依存性注入 • オブジェクトを外から「注入」すること – Dependency Injection、略してDIと呼ぶことが多い • Dependencyに「依存性」という訳が当てられているが、 本来の意味としては「オブジェクトの注入」である – 依存性逆転の原則(DIP)を適用した場合はこのDIが 必要になる
  99. 99. どの場面でDIは使うのか? • 依存性逆転の原則を適用した時 – 実際に使うクラスをインタンス化し、上位モジュールに 渡してあげる作業が「DI」
  100. 100. (Zenjectの話は一旦忘れて) 手作業でDIしてみる
  101. 101. ResourceProviderの例を使ってDI • 「ResourceProvider」というデータを提供してくれるクラスがある • 「ResourceProvider」は「Client」を使ってデータを取得してくる • 「Client」は抽象化されインターフェイスが定義されている • 「Client」の実装はプロトコルごとに複数用意されている
  102. 102. ResourceProviderの中身 • コンストラクタで外からインタンスを受け取る – クラス内ではインターフェイスしか触らない
  103. 103. ResoureProviderを誰が作るのか? • ResourceProviderの生成にClietも同時に必要になる • 2つまとめて生成する「Factory」を作ったほうが良さそう – デザインパターンのFactoryMethodパターンが近い
  104. 104. Factoryを作る • HttpResourceProviderFactory – HttpClientを使うResourceProviderを提供する
  105. 105. Factoryの実装 • ResourceProviderの生成時に使うClientを注入する
  106. 106. 手動でDIおわり • あとはFactoryを経由で ResourceProviderを作ればOK
  107. 107. 単純なDIだったら簡単
  108. 108. 実際はもっと複雑になる
  109. 109. 例えば • ResourceManagerクラス – ここにも依存性逆転の原則を適用した方が良さそう
  110. 110. こうなる • つまりFactoryのDIも必要になる – ResouceProviderの生成にFactoryが必要だった – じゃあFactoryのFactoryを作るのか…?
  111. 111. 他にも • HttpClientをConfigに依存させる変更を入れる、とか – どのApiサーバに通信するかをConfigで切り替える – ConfigをDIすることで挙動を変える
  112. 112. 依存性注入の問題 • 依存性の解決を誰が行うのか? – 依存関係が多段になるほど解決が難しくなっていく – 依存関係を解決する順番も考える必要が出て来ることがある • オブジェクト数が増えると人間の手では 管理できないほど複雑なDIが必要になってくる
  113. 113. 手動でDIには限界が出て来る
  114. 114. そこで使われるのが DIフレームワーク
  115. 115. つまりそれが Zenject
  116. 116. あらためてZenjectとは • DIを管理してくれるフレームワーク – オブジェクトの依存関係を簡単に定義できる – 自動的にDIを実行してくれる – Prefabの生成などにも対応
  117. 117. さっきの例 • Zenjectを使うとFactoryを使わずに書ける – 代わりに「DIコンテナ」という概念が出て来る (オブジェクトの関係性を定義するモジュール)
  118. 118. 1.Zenjectを導入 • AssetStoreから入れて終わり
  119. 119. 2. Installerを定義 • MonoInstallerを継承したInstallerを作る – ここにDIコンテナにオブジェクトの関係性を記述していく
  120. 120. 3. Injectアトリビュートをつける • 注入して欲しいところに[Inject]アトリビュートをつける – フィールド、またはメソッドに[Inject]をつけるとそこに注入してくれる – コンストラクタで注入している場合は何もしなくてOK
  121. 121. 4.SceneContextを配置 • シーン単位でDIを管理するマネージャオブジェクト – 1シーンに1個必要 – ここに先程のInstallerを登録 Installerを貼り付けて登録
  122. 122. 5.実行する • 後はZenjectがオブジェクトを注入してくれる – さっき作ってたFactoryみたいなのはZenjectがやってくれる – もちろん自分でFactoryを作ってInstallerに登録も可能
  123. 123. 6. 注入したいオブジェクトを差し替える時 • Installerを複数個定義して差し替えればOK
  124. 124. 以上がZenjectを使ったDIの例 • 依存性逆転の原則をちゃんと守って作ってあれば、 「Installer」に記述するだけで使えるはず • あとZenjectのDIコンテナを応用した機能もある
  125. 125. ついでに Zenjectの便利な機能
  126. 126. Scene Bindings
  127. 127. SceneBinding • Scene上にあるオブジェクトを登録して、 実行時にInjectしてくれる機能 – Unityのコンポーネント限定の機能 – 「Inspector ViewでコンポーネントをD&Dで紐付ける作業」 をZenjectに任せることができるようになる
  128. 128. Zenject使わないいつもの • 例:MainGameManager が GameTimerを 使う – [SerializeField]をつけてUnityEditorから設定する – いつもやるやつ Inspector Viewで設定
  129. 129. これをZenjectにやらせる 1.[SerializeField] を [Inject] に変更
  130. 130. これをZenjectにやらせる 2.Zenject Bindng コンポーネントを用意 – 貼り付ける場所はどこでもいい – ここに注入するオブジェクトを登録しておく (Installerに登録する作業を裏で自動でやってくれる)
  131. 131. Scene Bindingsの設定おわり • これでZenjectが実行時にコンポーネントを注入してくれる – 設定が外れてMissing 状態になるリスクを減らすことができる – 扱うコンポーネントの数が増えた時にも簡単に対応できる – シーンをまたいで注入もできる ハクレイフリーマーケットでの設定例
  132. 132. Scene Bindings のよさ • Singleton Mono Behaviourを消し去れる – 「インタンスの参照を簡単に取得できる」って理由で多用された SingletonMonoBehaviourの代替として使うことが出来る – Zenjectを導入しているならScene Bindings で コンポーネントを解決するようにしよう
  133. 133. 依存性注入とZenjectのまとめ • 依存性注入は必須テクニック – モジュールを疎結合にするとどうしても必要になる – DIしやすい形に設計していけるとよい • Zenjectはすごい便利 – 複雑なDIをする必要があるなら使うことをオススメ – Scene Bindingsを使えばEditor上のぽちぽち作業を減らせられる – Singleton Mono Behaviour の代わりに使うこともできる
  134. 134. ただし… • Zenjectの動作パフォーマンスはそれほど良くはない – 注入する時に内部でリフレクションが走る – 大量のオブジェクトを生成したりすると顕著に遅い – 導入するメリット・デメリットの見極めは必要
  135. 135. おしながき • 設計とは – 設計とは何か、設計の何がよいのか – モデリングとクラス設計 • 覚えておくべき基礎知識 – クラス図の読み方 – SOLID原則 – デザインパターン • Zenjectの紹介 – 依存性注入とは何か • まとめ
  136. 136. 最後のまとめ • 設計作業はプログラミングにおいて普遍的なもの – 設計について勉強するなら、Unityの参考書よりは プログラミングそのものについて扱っている本の方が 詳しく書いてあると思う • Unityのサンプルプログラムは設計原則守ってないヤツ多い • 設計の学習はトライ&エラーで経験を積むのが一番早い – 実際に経験しないと設計の話はピンとこない – 手を動かしていろいろ設計を試し、 失敗を繰り返して学ぶのがやっぱ一番はやい
  137. 137. 昔書いたQiita記事 • グローバルゲームジャムでクラス設計をやった話2017 – https://qiita.com/toRisouP/items/5b7814fda00cab120e39 • この講演を聞いた後に↑の記事を見返してもらえると 新しい発見があるかと思います
  138. 138. おすすめの本 • C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング – Gary McLean Hall(著),クイープ 訳 / 5,400円 – デザインパターン、SOLID原則、依存性注入について詳しく解説している
  139. 139. 以上 • ありがとうございました • @toRisouP

×