r_kajiya

r_kajiya

CleanArchitectureを元に考えたUnityのクラス設計④ - データの管理

概要 前回の記事ではロジックのつなぎ込みを説明しました 今回の記事ではマスターデータやプレイヤーデータなどデータの管理に関する説明していきます 前回の記事で少しだけ出たTimeZoneGateway(utcをベースとした各国時間帯に関連するマスターデータ)の部分です 一旦、今回の記事で最後にしようと思うので、今までの記事の解説に使用した時計アプリのプロジェクトURLを貼っておきます 省略している箇所のソースなども確認できるのでぜひご覧ください クラス図 Jsonの場合

¥500
r_kajiya

    • CleanArchitectureを元に考えたUnityのクラス設計③ - ロジックのつなぎ込み

      概要 前回の記事ではロジックについての設計を説明しました 今回の記事ではロジックのつなぎ込みを説明していきます クラス図 Context ContextはUseCaseを束ねる長のような存在でタイトル・ホーム・クエストな どUnityのシーンレベルごとに存在します Contextで使用するUseCase達を束ねて初期化や更新の呼び出しを行います さらに別Contextへの遷移も集約しています ClockContextを例にすると以下の機能を持ちます ・ClockU

      r_kajiya

      • CleanArchitectureを元に考えたUnityのクラス設計② - ロジック編

        概要 今回はiOSの時計アプリを真似して作ったアプリをもとに設計の解説していきます タイトルに書いてあるロジックを時計アプリで例えると ・クロック機能 ・タイマー機能 ・ストップウォッチ機能 などなど、アプリの機能のことをロジックと呼んでいます 今回の記事ではクロック機能を用いて、このロジックの考え方について説明していこうと思います 画面 クラス図 UseCase UseCaseはロジックのみを持つクラスです むしろロジックしか持ってはいけません 表示に使用するも

        r_kajiya

        • CleanArchitectureを元に考えたUnityのクラス設計①

          はじめにUnityでアプリを作ろうとするときに多くのプログラマがはじめに考えるのが設計だと思います 設計は開発効率やバグ発生率に大きく影響するため、頭を悩ましながら設計しますよね （チーム開発でもし変な設計してしまったなら未来永劫文句言われるし・・・） そんな設計に苦悩しながらも良き設計を求めて「Unity クラス設計」等で検索してるプログラマの方も多いと思います 検索結果にはSOLID原則やオブジェクト指向などの設計思想は多くヒットしますが、意外と実装が細かく書かれて

          r_kajiya