ゆる設計論会 with Sketch Knights

身内で開催したsketch knightsのコードを見ながら設計について緩く語る会のスライド。
メモは喋りながら突っ込まれたことなどのまとめ
Sketch Knights: https://team-sketch-knights.itch.io/sketch-knights

Transcript

1. ゆる設計論会 へのへのん 2026/01/23
2. 目次 概要 メッセージングライブラリ 設計・分割 pure C# DI Container 座談会
3. 概要 優しい目で見てください 適度に相槌などもらえると嬉しい
4. SketchKnights 略
5. SketchKnightsの仕様
6. 最終仕様イメージ チュートリアル 描画 待機 バトル リザルト を描く startを切る を描く を描く 敵スポーン hp0 時間経過 GameClear GameOver 説明 武器が生える 説明 ×3 ×3
7. クラスイメージ図 主に私が書いたやつ
8. MainFlow.cs 全体の進行
9. メッセージングライブラリ
10. メッセージングとは イイカンジに仲介してくれる 発信者 メッセンジャー 購買者 購買者 購買者
11. 何が嬉しい？ 疎結合性を担保できる 発 メ 購 購 購 発 メ 購 購 購 発 メ 購 購 購 発信者 メッセン ジャー 購買者 購買者 購買者
12. 何が嬉しい？ →再利用/拡張/保守などが容易 A メ 購 購 購 発 メ 購 購 購 発 メ 購 購 購 購 購 発 メ B メ 購 購 購
13. ⚠万能ではない 今回ちょっとやりすぎ感があるよ☆ 疎結合→読みにくくなる パフォーマンス
14. ライブラリの種類 いっぱいある Event/Delegate R3(UniRx) UnityEvent MessagePipe ZeroMessenger VitalRouter MVP ToolKit etc...
15. どれを使えばええねん 場合に応じて適切なライブラリをs... →とりあえずR3を使おう！ 早い！ 使いやすい！ 機能いっぱい！
16. コレさえ知っとけばOK Subject Subscrive IDisposable, .Dispose ReactiveProperty
17. 知っておくと幸せになれる CompositeDisposable Where等 ReadonlyReactiveProperty public readonly Observable .Add (きっともっとある)
18. メモ メッセージングライブラリを使うと疎結合→△ ...を使って、疎結合を実装している→◯ イベント駆動, メッセージングライブラリなど単語整理
19. 設計・分割
20. 設計? SOLID原則 デザインパターン めっちゃ主観を語ります
21. 今日の 樹形・ピラミッド
22. 自立した子供 一方向の依存
23. 何が嬉しい？ プログラミング大体全部これ 再利用/拡張/保守が容易 シンプル 適切な隠蔽
24. 分割 切り離せそうなら切り離す 短すぎ・長すぎを感じたらリファクタを検討する (100~300行 再利用性やデータの流れを考慮する 言語化ムジ～＼(^o^)／
25. 何が嬉しい？ →認知負荷が軽い 再利用/拡張/保守が容易 シンプル 適切な隠蔽
26. メモ Disposable c#の廃棄するための取り決め。 イベントの購読を適切に破棄しないとメモリリーク GCに回収されない。無限に重くなる Destructor c++とかにある、Constructorの逆。 c#はコレじゃなくてdispose使おう
27. pure C#
28. とは？ 純粋なC# 狭義 Unity非依存のスクリプト、C# 広義（？）→今回は主にコレ MonoBehaviour未使用のスクリプト、C#
29. 何が嬉しい？ Unity回避 コンポーネント、シリアライズ フィールド地獄から逃れられる →スクリプトをいじるだけで作業 が完結
30. 何が嬉しい？ テスト容易
31. 何が嬉しい？ その他副産物 パフォーマンス 別環境への切り離し Unityの過去負債から逃れられる ECSとかも楽になる？
32. 代償 ；； Unity機能へのアクセス 特に致命がSerializeField, LifeCycle(EntryPoint) 必要なデータのバケツリレー →これらを解決するために別のものに依存
33. メモ SOLIDのDを学ぶと良さそう interface(等)の意義 逆転学ぼう →聞いたことはあるがナンモワカラン、学びて～ 制御の流れと構造の流れが同じ ピラミッド的なノード構造
34. メモ 分割基準 再利用が必要 債務の分割 ただただ長い・短いで分割しない これもSOLIDらしい
35. メモ interfaceがあるとそれだけ読めば良い 計算処理だけ切り出す 命名
36. DI Container
37. そもDIとは データをイイカンジに外部から入れること = Dependency Injection、依存性注入
38. 具体例 データをイイカンジに外部から入れること Constructor Unity DI SerializeField .Find() DI Container Zenject VContainer
39. DI Containerとは あんまり理解できてない コンテナを用いていい感じにしようと言うやつ
40. DI Containerとは なんかいい感じにしてくれるContainer Container ClassA ClassA ClassB ClassB Register Register Resolve ClassC
41. 何が嬉しい？ スマートな依存解決
42. 何が嬉しい？ (ライフサイクル)
43. メモ モジュールの独立性、参照の方向 di containerで解決→✕ interface, pure c#などの設計で解決→◯ 確かに～知見～～
44. メモ →Constructorによる解決、newが増えてく →クラスがメッチャ増える、初期化順序の課題 →DI Containerを使うことで、初期化が簡単になる 依存の担保自体は人間が、注入は機械が
45. メモ 依存関係の整理 依存関係の方向を整理 findやinspectorのカオスを対処 dip