【プログラマー向け】クラス設計のリファクタリング#2

皆さんこんにちは！
ご閲覧いただきありがとうございます。

本日は前回に引き続き、制作者様向けに私が行った
リファクタリング方法を微力ながら解説させていただきます！

開発環境は以下の通りです。
・Unity
・VisualStudio 2022
・c#

何を行ったか

拡張するたびに、EnemyCore内のswitchケースの分岐が増えたり
条件式が冗長になるのは避けたかったのでシンプルに機能の切り分けを行いました。

それぞれのInterfaceに基本機能をつけ、EnemyCore内に以下の
変数を用意します。

このように定義すると、Setup関数内で継承先のクラスを自由に
アタッチすることができるので柔軟な設計になったかと思います。

改修前では自滅タイマーでの判定しか行っていませんでしたが
ここに追加条件が入ると、どの条件によって自滅しているのか
不具合が発生したときにどの条件で問題が発生しているか
分からなくなる設計になっていた。

またドロップ条件などもここに条件があるのはおかしいので
状態遷移の命令と自滅実行時の関数だけ呼ぶように修正

【before】

【after】

コインや経験値以外にドロップアイテムを増やしていく場合
Listにドロップ予定のアイテムを追加するだけでそれぞれの条件から
ドロップを行うか判断できるように修正

【before】

【after】

switchケースでそれぞれの処理を書いていたので、行動パターンが
増えるたびに追加しなければいけなかったり、〇〇の行動と△△の行動を
組み合わせた動作をさせたいときに、EnemyBaseを継承して専用の
処理を作る必要がありましたが

_enemyMovementに代入した
クラスの型を変更するだけで任意の挙動に切り替えることができ

特別な動作を作る場合も、IEnemyMovementを継承させた
EnemyMovementBossのようなクラスを作成することでよいので
量産を簡単に行うことができるようになりました。

【before】

【after】

量産や今後の活動に合わせてある程度
ソースの整理は行えたかなと思いましたが、MonoBehaviorを継承
させるかについてはいまだに迷いました。

実際にEnemyMovementクラスは移動座標量を計算して
渡しているだけなので、EnemyCoreから現在の座標やターゲット座標を
与えてもらうまで動かないので制約がきついので

今度挙動を追加する際に手間になってしまう気がします。
(現状でも振る舞いごとに渡すプロパティが違うので)

UnityAPIに頼る部分とそうでない部分の見極めは慎重に
行う必要があると改めて実感できました。

今回は以上となります！
新米プログラマーの書いた記事ですが、少しでも参考になれば幸いです！
最後までご閲覧いただきありがとうございます！