Tomotaka SUWA
t-suw****@users*****
2006年 7月 22日 (土) 11:27:43 JST
諏訪です。 次の課題は自動ダイナミック補完になるのですが、これを実現するにあたり、 現在の AquaSKK のコンポーネント部分の作り、実際のコードを何度も確認・検 討してみました。 その過程で、継承関係に着目したクラス図を起こしました。 # 所有関係を入れるとゴチャゴチャするので省いています。間違っているとこ # ろがあれば訂正するので教えて下さい。 http://aquaskk.sourceforge.jp/images/inputmode_hierarchy.png 図の中央あたりの IMSessionInputMode が、アプリケーション単位で作成され る AquaSKK のインスタンスで、窓口として動作します。 この設計のベースになっているのは、機能中心のアプローチだと思います。機 能単位でクラスを抽出し、その中で個別に状態を管理しています。 一方で、状態中心のアプローチも有効ではないかと考え、試しに状態遷移図を まとめてみました。まだ完全ではありませんが、とりあえずの雰囲気はつかめ ると思います。 http://aquaskk.sourceforge.jp/images/statechart.png 実際のコードでは、各ボックス単位でクラス化するイメージになります。入れ 子構造はクラスにするか、関数ポインタにするか、悩みどころです。 また、「確定入力モード」の部分はかなり端折って書いているので、実際には もっと複雑になると思います。 当然のことながら一筋縄ではいかず、何度も試行錯誤が必要になるでしょう。 ただ、状態中心アプローチのメリットである、状態が機能の中に埋もれない、 状態が複数の機能に分散しないという点は、そういったマイナス要因を打ち消 すほど魅力的で、最終的にはメンテナンス性の向上が期待できます。 逆に言うと、機能が状態の中に埋もれる、機能が複数の状態に分散することに なりますが、これは機能側の独立性と再利用性を高めることにも繋がるわけで、 一石二鳥の相乗効果が期待できるのではないかと、妄想しています ;-) ということで、自動ダイナミック補完を実装する前に、状態中心アプローチで コンポーネント部分を書き直したいと思っています。 おおまかな進め方は以下の通りです。 (1) 状態中心コンポーネントの追加(〜 10月末) 既存のコードは温存したまま、新しいコードを追加していきます。 環境設定にオプションを追加し、実績のある現在のコード(=レガシーエン ジン)を使うのか、状態中心のコード(=新エンジン)を使うのかを選択でき るようにします。 (2) 互換性の確保(〜 12月末) レガシーエンジンと新エンジンの互換性が 100% になるまで、ひたすらテ ストを繰り返します。 (3) 自動ダイナミック補完の実装(〜 来年 3 月末) 互換性が 100% になったら、新エンジン側に自動ダイナミック補完を実装 していきます。 (4) レガシーエンジンの切り離し(〜 ？) 新エンジンが充分にこなれ、安定度・信頼性の面で問題がないと判断でき た時点で、古いコードを取り除きます。 - * - 新エンジンの開発は、ブランチを切って進めるつもりです。何かご意見などが あればよろしくお願いします。 -- Tomotaka SUWA
Fork
