Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Humble Object Patternな話
Search
いも
February 21, 2019
Programming
2.3k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Humble Object Patternな話
Roppongi.unity #01の資料です
いも
February 21, 2019
More Decks by いも
See All by いも
UnityプログラミングバイブルR6号宣伝&Unity Logging小話
adarapata
0
640
Unityテスト活動のふりかえり
adarapata
1
680
Gather.townはいいぞ その後
adarapata
1
1.7k
Unityでの開発事例
adarapata
3
23k
どこのご家庭にもあるシーンマネージャーの話
adarapata
2
8.8k
Gather.townはいいぞ
adarapata
2
2.4k
宴はいいぞ
adarapata
0
2.2k
わかった気になるモブプログラミング
adarapata
1
180
モブワークっぽいのをやっている話/Trying mobwork
adarapata
2
1.3k
Other Decks in Programming
See All in Programming
freee が目指す データ マネジメント戦略 AI-Ready 時代を支える 攻めのガバナンスとは
freee
PRO
0
240
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
390
生成AI導入の「期待外れ」を乗り越える ー 開発フロー改革が目指す、真の組織変革
starfish719
0
3.8k
継続モナドとリアクティブプログラミング
yukikurage
3
680
VibeCodingからAgenticWorkflowへ
starfish719
0
180
Lean は証明の正しさを確認するためだけのツールって思ってませんか?
inoueasei
1
140
AIエージェントで 変わるAndroid開発環境
takahirom
2
770
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
580
壊れたパーサから始める関数型設計と構成的なパーサ #fp_matsuri
raiga0310
2
440
全PRの83%がAIレビューだけでマージできるようになった開発組織はその後どうなったか
athug
1
1.4k
テーブルをDELETEした
yuzneri
0
130
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
180
Featured
See All Featured
Joys of Absence: A Defence of Solitary Play
codingconduct
1
420
Between Models and Reality
mayunak
4
380
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
370
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
560
WCS-LA-2024
lcolladotor
0
790
Context Engineering - Making Every Token Count
addyosmani
9
1k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
brightonSEO & MeasureFest 2025 - Christian Goodrich - Winning strategies for Black Friday CRO & PPC
cargoodrich
3
760
What's in a price? How to price your products and services
michaelherold
247
13k
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
The Curious Case for Waylosing
cassininazir
1
450
Transcript
Humble Object Pattern な話 Roppongi.unity #1 2019/02/21 Roppongi.unity #1 2019/02/21
いもです いも(@adarapata) ゲー ムクライアントエンジニア adarapata.com Roppongi.unity #1 2019/02/21
ご注意 2019/1/23 にGotanda.unity #10 で発表した「 どこから始めるUnity Test」 の時間切れで話せなかった後半部分にフォー カスした内容です。 https://speakerdeck.com/adarapata/dokokarashi-meruunity-test
なので前回と若干被る話が多いのでご了承ください。 Roppongi.unity #1 2019/02/21
今日の話 Humble Object Pattern について Roppongi.unity #1 2019/02/21
前提 みんなテストが書きたくて手が震えている Roppongi.unity #1 2019/02/21
テストしにくさの元 密結合 static なインスタンス 入力イベントが絡む処理 UI が絡む処理 ファイル、DB などの外部リソー スが絡む処理
etc.. 実際問題、 どう綺麗に書いてもテストしにくい部分は出てくる Roppongi.unity #1 2019/02/21
テストピラミッド。 上位に行くほど難易度が高い Roppongi.unity #1 2019/02/21
コスト高いのでテスト避けたい わかる 時にはそういう判断も必要かもしれない 書かない ≠ 書けない 書けない理由は明らかにすべき。 ピラミッドの境界を跨ぐような処理を分割していく Roppongi.unity #1
2019/02/21
Humble Object Pattern とは テストしやすいものとしにくいものを住み分ける実装パター ン テストしにくいものの実装をHumble( 控え目) にする 多分初出は
xUnit Patterns http://xunitpatterns.com/Humble Object.html クリー ンアー キテクチャ本にも載ってたので有名かも Roppongi.unity #1 2019/02/21
public class PlayerUnit : MonoBehaviour { [SerializeField] private float _speed
= 1F; void Update() { var horizontal = Input.GetAxis("Horizontal"); var vertical = Input.GetAxis("Vertical"); Move(new Vector3(horizontal, vertical)); } private void Move(Vector3 direction) { transform.position += direction * _speed; } } きちんと任意の方向に動くかテストを実装したい Roppongi.unity #1 2019/02/21
書きにくさポイント 入力が絡むので書きにくい MonoBehavior の機能に依存しているので書きにくい SerializeField も同様 でも移動する部分は書きたい 書きやすいものと書きにくいものを切り分ける。 Unity における書きにくいものは大体MonoBehaviour
絡みなのでそこか ら切り出す。 Roppongi.unity #1 2019/02/21
public interface IPlayerUnit { float Speed { get; } Vector3
Position { get; set; } } // MonoBehavior 成分を0にしたけど、 移動ロジックを持つクラス public class PlayerUnitController { private readonly IPlayerUnit _unit; public PlayerUnitController(IPlayerUnit unit) { _unit = unit; } public void Move(Vector3 direction) { _unit.Position += direction * _unit.Speed; } } テストを書きにくいMonobehavior からロジックを抽出する Roppongi.unity #1 2019/02/21
public class PlayerUnitHumble : MonoBehaviour, IPlayerUnit { [SerializeField] private float
_speed = 1F; private PlayerUnitController _controller; public float Speed => _speed; public Vector3 Position { get => transform.position; set => transform.position = value; } void Start() => _controller = new PlayerUnitController(this); void Update() { var horizontal = Input.GetAxis("Horizontal"); var vertical = Input.GetAxis("Vertical"); _controller.Move(new Vector3(horizontal, vertical)); } } Roppongi.unity #1 2019/02/21
変更点 移動処理の詳細と、Monobehavior が離れた 具体的な処理は PlayerUnitController に任せるようになった テストしやすいものとしにくいものに分かれた ピラミッドの境界が明確になった 切り分けられたので、 移動処理のテストも書ける。
入力のテストはやらない! 移動処理を行う側はインタフェー スだけ見ているので、 差し替えが楽。 Roppongi.unity #1 2019/02/21
IPlayerUnit は状況に応じて差し替えられる Roppongi.unity #1 2019/02/21
IPlayerUnit は状況に応じて差し替えられる Roppongi.unity #1 2019/02/21
テストコー ド public class PlayerUnitTest { // テスト用のいい感じモック public class
MockPlayerUnit : IPlayerUnit { public float Speed { get; set; } public Vector3 Position { get; set; } } [Test] public void PlayerUnitMove() { var unit = new MockPlayerUnit { Speed = 5, Position = Vector3.zero }; var controller = new PlayerUnitController(unit); controller.Move(Vector3.up); Assert.AreEqual(new Vector3(0,5F,0), unit.Position); } } Roppongi.unity #1 2019/02/21
まとめ テストしにくい部分は発生する テストしにくいところとしやすいところを分けて、 書ける領域を増 やす Humble Object はそれらを切り分ける Roppongi.unity #1
2019/02/21