こんな人におすすめ
・人の設計を見てみたい、考え方を見てみたい
・音ゲーのノーツツール作成を考えている
・ツール作成に興味ある
開発環境
Unity2017.4.8.1f
VisualStudio2017Community
お品書き
・目指した設計と目標
・今回での利点と欠点
今回の仕様
・ノーツが配置できる
・3種類のノーツがある。
・線上の上にノーツが配置される必要がある。
・吐き出す際は、どのノーツのタイプに関わらず、一つ一つのノーツに分割する必要がある。
目指した設計と目標
設計思想としてClean Architectureを自分なりで理解と制作。
を行っていたのですが、最終的にできたのは、おそらく役割の分担が明確にできたクラス設計になるかと思います。
結果からいうと、以下の通り
よかった点
それぞれのクラスの役割が明確になったため、特定の機能を追加する際にどのクラスに追加が正しいかが明確になり
追加の動作をどこに実装しようかと考えた際に、どこに追加するのかが明確になった
クラスの役割が、明確になる利便性を理解した（気がする）
何か機能を追加する際に、Data側から作れば、表示部分はそこまで気にしなくてもいい（考えるときは表示部分から考える）
悪かった点
何かの変更内容に汎用的にはならなかった。
全てが追加追加のため、不要なソースも増えた。
当たり前かもしれないがDataクラスに変更が変わった際に、ほぼ全てが変更してしまう作りになっていた。
参考サイト
https://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc
設計部分
View部分を状態によって切り替えを行い、Viewには、表示だけを行った。
しかし、当初、データの取得部分とデータの編集部分を、全てDataAccesserを使用していたため、非常にFatなDataAccesserになってしまっていた。
というのも、このDataAccesserには、ノーツの編集に必要な情報と、描画の際に必要な加工部分が全て集約していたためです。
例えば、以下のような情報
//BPMと次のBPMの間の大きさ ノーツの位置を決めるのに必要なプロパティ
public float BPM_Width
{
get
{
return スクロールの長さ / BPMが何回表示されるか？
}
}
が10個くらいあって気づいたら、プロパティだけで、200行を超えていた。
そこで、Dataを、ノーツと関係ないデータ、ノーツ関係のデータと、ノーツに対して編集を行うクラスでDataAccesserの役割を分割した。
そのData部分にも、Dataと編集して得るデータをとるためのクラスを間にかます事で分割を図った結果が以下の図。
View部分のざっくりクラス図
Viewに関しては、StateSwitchクラスから、それぞれのViewクラスに対して呼び出しと、切り替え時にDataAccesserクラスを引数として渡します。
このクラス自身にDataAccesserをここで持つことで、読み込んでー＞編集の場合でも、新規ー＞編集の場合でも、どちらも同じ部分を参照として、そこから、データの格納部分と、編集部分をそれぞれ用意するだけで良いため、共通部分で持っています。
データ格納のざっくりクラス図
Dataの格納に関しては、DataAccesserを通じて、基本的には行いますが、設定数値（スクロールの大きさ、BPMなど）を取得できるSafetyクラス、実際のノーツを管理するCollectiveクラスがあります。
Collective自身は、ノーツを複数管理しています。
理由としては、長押しタイプのノーツなどの複数のノーツによって構成されるタイプのものに合わせたため。
その先のOneEditorNorts部分では、主に、エディターの表示だけの情報を保持しており、OneNortsの参照を保持しています。
ノーツの純粋なデータとしては、このOneNorts部分のみが保持するつくりになっていいます。
役割を分割している設計をしていった感じの所感。
分割するのは、役割をすごく明確にできていて変更箇所がすごく明確。便利。
一方何かのデータをとってくるのに、これの荒れ野これのってなって長くなりがち。
なので、2階層までに使う先のデータを取得できるくらいがたぶん限界、できれば、1階層くらいで使用できるものがあればいい感じになったのではないかと感じた。