このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
大分と構造が変わったので、
ここで一度、以前と同じように動作するかどうかテストしよう。
RFBSession クラスに詰め込んでいた処理を、
全て外部のクラスを利用するように書き換える。
========== RFBSession#execute ==========
/**
* RFB プロトコルの開始点。
* @param in 汎用入力ストリーム。
* @param out 汎用出力ストリーム。
* @throws IOException 入出力エラー。
*/
public void execute(InputStream in, OutputStream out) throws IOException {
// 基本オブジェクトの用意
RFBContext context = new RFBContext();
RFBInputStream rin = new RFBInputStream(in);
RFBOutputStream rout = new RFBOutputStream(out);
// テスト用の値
int serverVersion = 3007; // 3.7
SecurityHandler securityHandler
= new VNCAuthenticationHandler("password");
// ProtocolVersion ハンドシェイク
{
ProtocolVersionHandshake handshake
= new ProtocolVersionHandshake(serverVersion);
handshake.execute(context, rin, rout);
}
// Security ハンドシェイク
{
SecurityHandshake handshake = new SecurityHandshake(securityHandler);
handshake.execute(context, rin, rout);
}
// メイン処理
processMain(context, rin, rout)
}
========== end of RFBSession#execute ==========
テスト用の値を変更しながら実行してみたが、
特に問題なく同様の結果となることが確認された。
さて、RFBSession は以前と比べて、
クラス内がシンプルになり、非常に見通しが良くなった。
基本的に、メソッドの行数を短めに抑え、
意味のある単位でクラスに分けることは、
ソースコードの保守性を高める上でメリットが多い。
ただし、クラスやメソッドが増えると、
処理をトレースするのが困難となるというデメリットもある。
特に、インタフェースを基準としたクラス化を行うと、
インタフェースを実装したクラスの実行時型が分かりにくく、
ソースコードを目で追う（所謂机上デバッグ）のが難しい。
トレースは、手続き型プログラミングの時代からある手法で、
オブジェクト指向設計の考え方とは反する部分もある。
このあたりのバランスを考えるのは意外に難しい。