このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
RFBSession が落ち着いてきたので、
やっと次のステップに進める。
画面データやバッファの実装について、
かなり前に考えて放ったらかしだったので、
それを組み込む方法を考えていきたい。
現在のクラス構造を整理して見ると、
以下のクラスやインタフェースが基本となっている。
●処理系
jp.loafer.rfb.RFBHandler（処理・手続き）
●データ系
jp.loafer.rfb.RFBContext（ステート）
jp.loafer.rfb.message.Message（データの基本モデル）
●入出力系
jp.loafer.rfb.io.RFBInputStream（入力）
jp.loafer.rfb.io.RFBOutputStream（出力）
一般的なプログラムをデータフローに基づいて分解すると、
「入力」から「データ」を読み取り、それを「加工」し、
最後に「出力」するというのが基本的な流れだ。
上記はそれに従って作成した最も「低水準」のクラスであり、
RFB 仕様を整理してなるべくそのままクラス化したものだ。
さて、低水準のクラスは最も高い柔軟性を発揮する。
余計な処理（お節介）が含まれないので、
実装者の意図のままにどんな処理でも行う事ができる。
しかしながら、ちょっとした処理を行わせるにしても、
そこそこの量のコードを書く必要がある。
これは柔軟性の代償と言う事だ。
より汎用な物を目指せば、低水準になり再利用性が高いが、
具体的な実装を行うために手間が掛かるようになる。
つまり、面倒くさい・使いにくい物になりやすい。
より具象的なものを目指せば、高水準となり、
すぐに利用できるものができるが、特定用途に限定されたり、
ちょっとした拡張や例外的な処理が困難となる。
基本的に、クラスを設計する際は、
これらバランスをどうするかを考えながら行う事になる。
通常、最初から高水準なものを作るのは無駄が多いため、
まずは低水準のクラス群（ライブラリ）を実装しておく。
そして具体的な実装の定石となる「パターン」を見つけ出し、
それを実装した高水準のクラスを用意する。
これら高水準のクラスは、低水準のクラスを内部で持つか、
低水準のクラスを継承している事が多い。
前者は低水準のクラスを隠す方法であり、
委譲やカプセル化、ラッピングとも呼ばれる。
この場合、実装者には低水準のライブラリは見えないので、
実装水準においては明確に分離した階層構造を形成する。
後者は既定の実装を提供する方法であり、
ある程度パターン化された基本実装を提供し、
実装者のコード量を削減させる方法である。
この場合、実装者は必要に応じて既定実装を
オーバーライドする事ができる柔軟性があるが、
低水準のクラスのことを知っていなければならない。
実装水準においては依存性を含む階層構造を形成する。
さて、今回の RFB 実装で考えてみよう。
次にやるべきことは、メイン処理の実装である。
低水準の視点で考えれば、RFBHandler 実装クラスを作り、
ごちゃごちゃコードを書くだけということになるが、
それは非常に面倒になる事が容易に想定される。
何せ、RFBHandler インタフェースは、
execute というメソッド 1 つしか用意していない。
ハンドシェイクのようにシンプルなものであれば、
RFBHandler 実装クラスを用意するだけで済んだが、
RFB のメイン処理はかなり複雑になる事が想定されるため、
構造化した高水準の実装を用意したい所である。