More Related Content
What's hot (20)
Similar to と?こに何を书くのか? (20)
More from pospome (7)
と?こに何を书くのか?
- 1. どこに何を书くのか?
- 12. 注意点 ?元々ソーシャルゲーム作ってたので、 こーゆー系の例しか思いつきません??? ?今回はクラスを対象に説明します ?コードは golang で書いているので、 正確には class ではなく、struct なのですが、 まあ、大体一緒なので読み替えて下さい。
- 13. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Println(u.Attack) }
- 14. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Println(u.Attack) } 攻撃力計算のロジックが Attack と独立して管理されている 他の場所で同じように攻撃力計算をしたい時に ロジックが重複する可能性がある 例：バランス調整のシミュレーター 開発で利用するデバッグ機能など
- 16. type User struct { Attack int //攻撃力 } func (u User) GetAttack() int { rand.Seed(time.Now().UnixNano()) return u.Attack + rand.Intn(10) } func main() { u := User{ Attack: 100, } fmt.Println(u.GetAttack()) } User に GetAttack() を持たせることで、 Attack と攻撃力計算のロジックが常に一緒になる User が存在すれば、 常に攻撃力計算が可能になる
- 17. これで翱碍?
- 18. type User struct { HP, Attack, Defense int Job string Condition int } 先程の修正でもよさそうだが、 ユーザーは攻撃力の他にも属性を持つ事が多い User がロジックを持ってしまうと、 各属性に関する処理を全て User が持つことになる User クラスの責務がどんどん肥大化してしまう
- 20. type User struct { Attack Attack //ここがポイント } func (u User) GetAttack() int { return u.Attack.GetPoint() } type Attack struct { Point int } func (a Attack) GetPoint() int { rand.Seed(time.Now().UnixNano()) return a.Point + rand.Intn(10) } func main() { u := User{ Attack: Attack{ Point: 100, }, } fmt.Println(u.GetAttack()) } Attack を int ではなく、 オブジェクトと捉える Attack 自体にロジックを持たせる User は Attack.GetPoint() を呼ぶだけ 具体的なロジックは知らない
- 21. 攻撃力計算ロジックを Attack に実装することにより、 User クラスからその責務がなくなった これにより User クラスの責務が 肥大化する可能性は低くなるはず ＊Attack.GetPoint() をデリゲートしているので凝集度は低いですが???
- 22. さらに、攻撃に関する仕様変更は Attack という より具体的なオブジェクトへの修正に限定される 仮に守備力がある場合、 Defense という具体的なオブジェクトへの修正に 限定されるはず User が直接ロジックを持っている場合、 攻撃力、守備力など User が持つ全ての属性に対する修正は 全て User への修正になってしまう 適切な責務の分離ができているとはいい難い
- 23. 数値（int） である 攻撃力（Attack） を わざわざオブジェクトで扱うのはおかしい 数値は int で表現した方がいい と思う人がいるかもしれない???
- 24. 実はこれが今日のポイント
- 25. ?そのロジックはそこにあっていいのか? ?本来あるべきパッケージ、クラスがないのではないか? ↓ ?攻撃力計算ロジックを User に置いていいのか? ?本来あるべき Attack クラスが存在しないために User に置いてるだけではないのか? レビュー、リファクタリングには こういった観点で物事を考える
- 27. type User struct { Attack Attack //攻撃力 } func (u User) GetAttack() int { return u.Attack.GetPoint() } 攻撃力計算ロジックは Attack クラスが持っているので、 User クラスは変わらない
- 28. type Attack struct { Point int AttackLogic AttackLogic } func (a Attack) GetPoint() int { rand.Seed(time.Now().UnixNano()) return a.Point + rand.Intn(10) + a.AttackLogic.Calc() } type AttackLogic interface { Calc() int } type XxxEvent struct { Point int } func (x XxxEvent) Calc() int { //Xxx というイベントでは攻撃力が2倍になる return x.Point * 2 } AttackLogic interface を新規作成 AttackLogic を満たすクラスを Attack にセットすれば、 目的に合った攻撃力計算が可能になる 今回は Xxxイベント というイベント用の AttackLogic を用意している
- 29. func main() { point := 100 u := User{ Attack: Attack{ Point: point, AttackLogic: XxxEvent { Point: point, }, }, } fmt.Println(u.GetAttack()) } AttackLogic の管理方法はちゃんと考える必要があるが、 時間ないので割愛
- 31. そして、 この実装を通じて以下であることが分かる Attack … 攻撃を表現するオブジェクト Attack.Point … 攻撃力を表現する int 実は Attack は攻撃力のオブジェクトではなく、 「攻撃」という概念をオブジェクトにしている 攻撃力である Attack.Point は結局 int
- 32. ?そのロジックはそこにあっていいのか? ?本来あるべきパッケージ、クラスがないのではないか? ↓ ?攻撃力計算ロジックを User に置いていいのか? ?本来あるべき Attack クラスが存在しないために User に置いてるだけではないのか? ↓ ?「攻撃力」とは別に「攻撃」を表現するオブジェクトが 存在しないのではないか? ?攻撃と攻撃力は別々の概念として扱うことで 責務をはっきりさせる
- 33. まとめ
- 34. 今回の例であれば、 Attack は int のままでもいいかもしれない ただ、それはどーでもいい 今回伝えたかったのは「正解」ではなく「選択肢」 設計の正解を定義するのは難しい どこに何を书くのか? をしっかりと考えて、 自分なりに正しい選択をして欲しい
- 36. クラスが多い = 複雑 と考えるかもしれないが、 クラスを少なくしても結局必要なロジックは同じ 少ないクラスに大量のロジックを書くのか? 大量のクラスに短いロジックを書くのか? この違いでしかない
- 40. おわり