以上で、PC から Python を使用して NXT を制御する準備が整いました。

RtcTemplate などを使用して、NXT のコンポーネントの雛形を生成してコーディングに取り掛かりたいところです。 NXT Python はきれいにまとまっている Python モジュールですが、NXT Python のコードを直接 RTC の雛形に書き込むのはちょっと待ってください。

サンプルを見てもわかるように、NXT Python はロケータ、モーター、センサー等の複数のモジュールから構成されていて、モーターやセンサーへの細かな機能も制御できるため、アクセス方法も若干煩雑です。

ここは、NXT Python の複数のモジュールをまとめてひとつのインターフェースからアクセスするためのクラスを作ることにします。 これはソフトウエアパターンで言うところの Façade パターンになります。

Facade パターンあるいは Facade パターン（ファサード・パターン）とは、GoF（Gang of Four; 4人のギャングたち）によって定義された、コンピュータソフトウェアのデザインパターンの1つです。 Facade とは「窓口」を意味します。関連するクラス群を使用するための手続きを、窓口となる一つのクラスに集約することにより、プログラムの冗長性を無くすことを目的とします。(出典: フリー百科事典『ウィキペディア（Wikipedia）』Facade パターン)

こうした便利クラスを作成すると以下の利点があります。

• 作成したクラスを RTC 以外にも利用できる
• デバッグが楽になる
  • Façade クラス単体でデバッグした方がデバッグしやすい
  • 直接 RTC 化すると、この例で言えば、NXT Python の使い方の問題なのか、RTC の使い方の問題なのか切り分けが難しい
• 変更がしやすくなる
  • Façade クラスを変更しても、インターフェースを変更しなければ RTC側のコードは変える必要がない
  • たとえば、get_xxx()、set_xxx()といった関数の入出力にリミッタをつけたい場合、Façade クラス側のみの変更で済む
• NXT 以外のデバイスへの変更が容易になる
  • たとえば、NXT の次のバージョンのブロックが出た場合、インターフェースさえ同じであれば、対応が容易になる。

これは、RTC を作成する際全般に言えることです。 対象とするロボットやデバイスなどを、うまくクラス化することで、デバイスの変更や、RTC 自体の変更・バージョンアップにも柔軟に対応でき、変更に強いソフトウエアを作ることができます。

決して、onExecute() などで

ioctl(xxxx, xxxx); // UNIX デバイスへの直アクセス inb(xxx); // I/O への直アクセス outb(xxx); // I/O への直アクセス

のようなプリミティブな関数呼び出しをしてはいけません。 理想的には、

 onExecute(ec_id)
 { //　擬似コード
      if (m_inport.isNew())
     {
        retval = m_myrobot.set_actuator(m_inport.read());
        if (retval == fatal_error) return RTC::RTC_ERROR;
     }
     if (myrobot.get_sensor(sensor_data) == true)
     {
         m_outport.wrtie(sensor_data);
     } 
     else
     {// リードエラーの場合の処理
         if (fatal_error) return RTC::RTC_ERROR;
     }
     return RTC::RTC_OK;
 }