設計と難所への挑戦

振る舞いの分析

1. [吉田] 今回は動的な分析をするんだったね。
2. [舟元] そう、そう。この前は静的な分析だったから、ベーシックステージ、ボーナスステージ、難所の順番なんかが分からないままだからね。
3. [吉田] (>.

1. [舟元] 前回分析した、「感知する」と「切り替える」に注目してみたらどうかな？ステージや難所の前には灰色のライン「マーカー」があって、それを感知したら切り替える。
2. [吉田] なるほど。マーカー駆動、マーカードリブン、MKDか！
3. [舟元] 。。。
4. [吉田] アウトコースの振る舞いをベタで分析するとこんな感じかな？

1. [舟元] そうだね。インコースも同じようになるだろうね。次はこいつらを基に設計していこう。

いざ設計

1. [吉田] 設計ってのはソフトウエアとしてどうやって実現するかを検討することだよね。
2. [舟元] うん。前回の分析結果を基に静的構造から考えると良いと思うんだけど、まず、前回の結果の切り替える部分を全部洗い出すところから始めようか。
3. [吉田] だね。こんな感じかな。
4. [舟元] うんうん。

1. [吉田] マーカーを感知するごとに切り替えるんだよね。どうしようかな？「感知する」、「切り替える」ってのは動作だし、「ルックアップゲート」とか「ET相撲」は「走り方」が違うだけで「走る」っていう点で同じようなナカマって感じ。仲間ね。
2. [舟元] うん。うん。「どうやって走行するかが違う」というところが大事だね。「どうやって走行するか」っていう事柄に対して、その特徴（「どうやって」の部分）が何パターンかある。って気付けたら、設計の方針が何パターンか出せるね。

1. 抽象クラスを設けて、サブクラスで走行方法の差分を実装する。
2. インターフェース設けて、実装クラスで走行方法を実装する。

1. [舟元] 抽象クラスにするか、インターフェースにするかは、共通度合いとかで使い分けたりするかな。あとは、実装言語の仕様とかも気にしないといけないね。
2. [吉田] （さすが経験者。。。）じゃあさ、具体的に「どうやって走行するか（実装であったり制御方法であったり）」は後で考えるとして、「走行の仕方」って捉えられそうなモノをピックアップしてまとめてみよう。まずは、親クラス、、、抽象度の高い表現で「走行状態」とでもしておこっか。で、この「走行状態」クラスのサブクラスになりそうなものは、走り方だから、難所とかだよね、、、っと、こんな感じかな。

1. [吉田] 「平面走行」と「坂道走行」は「ベーシックステージ走行状態」という一つのクラスにまとめたよ。
2. [舟元] 「感知する」とか「切り替える」はどうする？
3. [吉田] それって、動作だから「走行体」にさせれば良いんじゃないの？「走行体」がマーカーを感知して、状態を切り替える。どうかな？