ゴマちゃんフロンティア

気まぐれと勢いで作るUnityゲーム開発日記です。

【プログラムメモ】ソースコードのリファクタリングについて

time 2015/11/09

というわけで、寒さが厳しい日が続く山梨です。
会社の開発室はマシン温度からか暖かくなることが多いのですが、ちょっと外に出ると肌寒い感じです。
家の灯油も補充しておいた方がよさそうです。

今回はタイトル通り、ソースコードの扱いについてのお話です。
というのも、新しい機能を実装しようにもクラス関係はソースが煩雑すぎて、思うように進めないことが多くなっているためです。
なので、各クラスの役割を明確化し、それに沿ってリファクタリングを行おうと思います。

ここで記載するものは自己流なので、当然ですが正しい扱い方とは限りません。
あくまでも参考程度ということで・・・。

コントロール系

最もシンプルで、オブジェクトのコントロールを担うクラスです。
キャラクターや物などのオブジェクトは勿論、各種判定や音などもこれになります。

当初はパラメータ(フィールド)を別クラスに持たせようかと考えたのですが、
・クラス内で扱うパラメータを外部に出すのはよろしくない
 →データベースや外部システムと連携しているわけではない
・カプセル化すると呼び出す度にゲッタやセッタを使うことになる
 →Update()などの処理で大量に呼び出すことになってしまう
・そもそもパラメータが外部に分ける必要があるほど多くない

などの理由により、普通にコントロール系クラスに持たせることにしました。
見直すと関数内で一度しか使っていないような変数もフィールドに書いていたりするので、整理すればスッキリするかもしれません。

どうしても長くなってしまうので、コメントやXMLドキュメントはしっかり書いていきます。
VisualStudioなら日本語も扱えるのでやりやすいです。

マネージャ系

複数のオブジェクトを管理したり、ステージ・シーン全体の管理を行うクラスです。

例えばゲーム全体を管理する「GlobalManager」というクラスでは、スクリーンショット機能やログ出力機能を実装しています。
ステージの進行状況を管理したり、敵やオブジェクトの出現を管理するものが多くなりそうです。

サービス系

定義が曖昧ですが、「複数のオブジェクトから参照される処理」を実装するクラスです。

例えば攻撃判定の生成はプレイヤーも敵も行うので、サービスクラスに書いています。
役割的にインターフェースを被っていそうですが、こちらはサービスを通して実装しているので中身も共通です。

パラメータの初期化などもこちらでいいかなーと思いますが、プレイヤーと敵で持ち方が異なるので不適切かと思われます。
「プレイヤーだけ」「敵だけ」ならスーパークラスのStart内で十分なので、線引きをしっかりしていきたいです。

ユーティリティ系

サービスクラスの静的な機能をまとめたもの・・・でしょうか。
「オブジェクトを取得」「一定の処理を行う」等の汎用性の高いものはこちらにまとめようと思います。

定数系

その名の通り、定数を定義しておくクラスです。
定数の種類によって「System」「Game」などと分けて管理しています。
性質上、全て静的で実装のないクラスになります。

定数の使い方はブログ移行時に再度まとめてあります。

インターフェース系

あまり使うことはないと思われますが、インターフェース用のフォルダを作っておきます。
C#のインターフェース名は先頭に I を入れるのが普通らしいので、その命名規則に従います。

Animator系

AnimatorControllerのステート用のスクリプトで、「StateMachineBehaviour」を継承しているクラスです。
これだけは扱いが大きく異なるので、専用の名前空間で分けておきます。

まとめ

そんなわけで、クラス毎の役割を明確化し、簡単なリファクタリングを行ってみました!
漠然とスクリプトを追加していくよりは、一定のルールに沿って作っていく方が統一性があり、分かりやすくなります。
今後新しくスクリプトを作る時は気を付けていきたいですね。

スポンサーリンク

down

コメントする



ツイッター