はじめに
UnrealEngineでの良い設計を学ぶために、以下の本を読みました。
UnrealEngine5でのBPオンリー開発勢でも役に立ちそうな学びを自分用にメモしました。
せっかくなので記事にして共有します。
未完成ですが、読み進めつつ足していく予定です。
対象者
この記事は下記のような人を対象にしています。
- 駆け出しUnrealEngineエンジニア
- 自分でも全体像が見えないような設計になっちゃうのをなんとかしたい人
学びMEMO
第２章 設計の初歩
変数名・関数名・クラス名は省略せずにわかりやすくする
改めて気を付けような。isGoodみたいなBool変数作っちゃダメだよ。
変数を使いまわさない、目的ごとの変数を用意する
ちゃんとつけた名前の役割だけを担うように！変数がいっぱい生まれるのは止む無し！
意味のあるまとまりで関数にする
Keep it simple, stupid!! 分けすぎてるくらいが丁度いい！
関係するデータとロジックをクラスにまとめる
独立した機能ごとにActorComponentやらGASを作ろう。
データクラスは避ける。
第３章 クラス設計 ～すべてにつながる設計の基盤～
クラスが単体で機能するようにする
そして、そのクラスをテストする用のクラスを作っておくと便利だよって最近教わりました。
Componentにガード節を用いる
処理の対象外となる条件をメソッドの先頭に定義することをガード節って言うらしい。
引数に不正値が入ってきたときにエラーを吐くようにしておけば、不正値のまま処理が進むのを防げる。
BPコンポーネントにはコンストラクションスクリプトがないからBeginPlayに書くのがいいかな。
第４章 不変の活用 ～安定動作を構築する～
引数で状態を受け取り、状態変更せず、値を返すだけの関数が理想
状態を変更する責任は、その状態を管理するクラスにあるべき。
そうでないと、状態がどこで変更されているのか把握しきれなくなる。
例えば、アクターコンポーネント内の関数で、親の変数（状態）を変更するような仕組みにするのは避ける。
変数作った時に、privateにチェックつける癖つけてもいいのかも？
第５章 低凝集～バラバラになったモノたち～
凝集度は高いほうがいい
凝集度とは「モジュール内における、データとロジックの関係性の強さを表す指標」。
つまり「クラス内におけるデータとロジックの関係性の強さ」。
データクラスは、低凝集であることから望ましくない。
低凝集のデメリット
低凝集だと、重複実装が起きやすい。データクラスに対する処理があっちこっちに書かれやすいから。重複実装によって修正漏れが起きやすく、可読性も悪くなる。
共通処理クラス（Common, Util）の罠
低凝集を推し進めてしまう可能性がある。
お互い関連のない雑多なロジックが実装されてしまっている場合が多い。定義集な構造を多く作りこんでいる状態。
安易に共通処理クラスを作らない！
横断的関心事
さまざななユースケースに広く横断する事柄を横断的関心事といい、これは共通処理としてまとめあげてよい。
- ログ出力
- エラー検出
- デバッグ
- 例外処理
- キャッシュ
- 同期処理
- 分散処理
多すぎる引数
.
.
.
続く...。
おわりに
まだ読み終わっていませんが、ゆっくり読み進めつつ内容を足していきます！
設計の勉強はスキ！