はじめに
今回はUnityがデザインパターンに関しての記事を出したので、ぼちぼち目を通していく記事です。
唐突に公式がデザインパターンのサンプルを公開したので、自分なりに咀嚼して意見を述べたいと思います。ちなみに翻訳版ブログでは一部のみの解説になっているので、本家のブログを見るのをお勧めします。
SOLID原則
単一責任の原則
ひとつのクラスにひとつ機能だけを持たせる。なので、所謂神マネージャーのようなクラスはNGってことですね。PlayerMoveとか、PlayerAnimationとかにすることで他のクラスに変更を与えないようにしましょう！ってことですかね。
オープンクローズの原則
機能の拡張を行いやすくしましょう！ただし、その際に修正が入らないようにしよう！Unityを始めたての時は以下の様にTagや衝突したObjectの名前などで判定をしがちですが、この場合衝突を判定したいObjectが増えた時は、その都度名前やTagの条件分岐を増やしていくのでこの原則だとNGです。また、兎に角見にくいので辞めたい方法でもあります。
gist74e2a7d2a1488768185f42e1d0561241
こんなかんじでInterfaceで実装することで、機能を追加しても修正が入らないようになりました。
gist97867156eed274e682422ef51e7c1da5
リスコフの置換原則
基底クラスでのルールを派生クラスで破ってはいけない。具体的には、フィールドやメソッドのアクセスレベルとか条件を上書きしたり、強めるのはNGみたい。単純な話派生クラスで基底クラスのメソッドとかを上書きする形でいじると、基底で実装した内容が消えたり、意図した動作をしなくなるので辞めようね！と云う事らしい。
インターフェース分離の原則
インターフェースは細かく分けて定義しよう。細かく分けることで、使わない機能を実装しないようにしようってことらしいです。Interfaceは何個でも実装可能なので細かく分けちゃいましょう！
依存性逆転の原則
上位モジュールは下位モジュールに依存してはいけない。ここで云う上位モジュールは、下位モジュールを使う側の事で、下位モジュールは上位モジュールに使われるクラスの事です。まあイメージとしては、クラスAとBがあってAが直接BをNew()してから、Bに定義されているメソッドを呼ぶのはいかんよねって話ですね。
Destroy()自体が一つのクラスのみで使用するなら問題はないのですが、他のクラスでも同じように呼べるようにしたい場合や、引数を変更した場合はその都度修正しなきゃいけないのでめんどいってことです。
これはInterfaceを使うことで解決します。Interfaceを介して実行することで、引数がそれぞれ変わっていたとしても呼べます。これがInterfaceを使う前の物と比べて依存性が逆転しているので、そのまま「依存性の逆転」と呼ぶみたいです。まあ、抽象に依存するべきってことですね。
Factory
抽象クラスと具象クラスを使って、クラスの機能・責任を小さくすることで、変更があった際にも少しの修正で、生成をまとめて管理するぜ！って考え方です。また、使う側は単純にCreate()を呼び出せば良いので便利だったりします。以前Factoryパターンについて試したので、記事を置いておきます。
おわりに
原則として知らなくても意識していたことが多かった印象でした。次回も引き続きデザインパターンを観ていきますよ！
是非、読者登録をしていただくと助かります！
