●シリーズ
- 【Unity】公式プロジェクトから、デザインパターンを学んでみよう(Part 1:単一責任の原則)
- 【Unity】公式プロジェクトから、デザインパターンを学んでみよう(Part 2:開放・閉鎖の原則)
●はじめに
- Unityを利用しながら、デザインパターンについての理解を深めようと思います。
- 筆者はデザインパターンを知らないです。本記事を書きながら学んでいきます。先人方からすれば、低質な記事だと思いますが、ご了承ください…。
- 本記事に間違いなどがあれば、コメントからご教授お願いします。
また、内容が結構ボリューミーなので、デザインパターンごとに記事を投稿させていただきます。
今回の記事では、簡単な概要と、役に立ちそうなサイトや記事を紹介するだけです。
●該当のプロジェクトについて
○リポジトリ
↓こちらのリポジトリから、Unityの公式のプロジェクトがダウンロードできます。
↓また、こちらのサイトの中から説明のPDFをダウンロードできます。(※全て英語です)
○内容
- プロジェクトの内容は、こんな感じです
- SOLID原則
- Factory Method
- ObjectPool
- Singleton
- Command
- State
- Observer
- MVP
- SOLID原則のフォルダ(フォルダ番号:1~5)は、スクリプトのみです。
- それ以降のフォルダ(フォルダ番号:6~12)は、シーンやGameObjectが含まれていて、ゲームを実行して挙動を実際に操作できます。
- General, ScriptTemplatesフォルダはほぼ無関係です。素材とかが入ってます。
※ スクリプトやシーン内のテキストは全て英語なので、Google翻訳を駆使して、解読頑張りましょう！！！
●デザインパターンについて、簡単な概要
※僕もちょうど昨日、デザインパターンという存在を知ったので、あんまりしっくりしてないところがあります…。すっごいゆるふわな説明になるので、ガチガチな記事が読みたい方はブラウザバックしてください！
○SOLID原則
- 5つの原則の総称がSOLID原則。
- クラスとか関数の拡張がしやすくなったり、コードの可読性を高めるための原則 です。
- 以下にめちゃくちゃ簡単な説明つけときます。正直自分でも全然分かってないです。
- 詳細な説明は、後日投稿予定の各記事に記載します。
① 単一責任原則(SingleResponsibility)
- 1つのクラスに、色んな機能を詰め込みすぎたらダメっていう原則。
- 例えば、「Player」クラスじゃなくて、[PlayerAction],[PlayerAudio],[PlayerAnimation]みたいに、細分化すればバグも少なくなったり、分担作業もしやすくなる。
② 開放・閉鎖原則(OpenClosed)
- 拡張には開放的で、変更には閉鎖的に対応しろっていう原則。
③ リスコフの置換原則(Liskov Substitution)
- 子クラスは、親クラスができることは必ずできるようにしろっていう原則。
④ インターフェース分離原則(InterfaceSegregation)
- 細分化して、必要な関数だけ実装しろっていう原則。
⑤ 依存性逆転原則(DependencyInversion)
- クラスは、そのクラスよりも下のクラスに依存するなっていう原則。
- 抽象(インターフェース)に対して依存するようにするべき らしい。
以下製作途中です