watermint.org

新たに設計を始める前に、もっとも類似で参考とすべきクラスJTableを使ってみての感想まとめておきます。今回はリハビリ目的と言うこともあって、JTableを拡張するよりは、JTableではなく全く新たにコンポーネントを設計しようと思っています。これは、JTableだけでなく、画面スクロールのためのJScollPaneも同様に新たにこの方眼紙コンポーネントのために設計することにします。では、既存のSwingコンポーネントJTableとJScrollPaneを使った場合の問題点を。

• TableModelが抽象的すぎる。ある程度複雑な表を扱おうとすると、TableModelが定義しているインタフェースでは不足ぎみです。リッチな表現を実現するためには、JTableかTableModelのどちらかでレンダリングのためのコンテキスト情報（たとえばセル結合とか、背景色とか）を持つ必要がありますが、現状のJTable・TableModelのコンビネーションではこれらのデータを扱う方法が十分考慮されているようには思えません。TableModelを実装したクラスでそれらの情報を管理しても良いのですが、TableModel相当の実装が渡されたときの互換的な振る舞いを定義するのが面倒なことと、より適切にテーブルモデルを設計することもリハビリの一環と考え車輪の再発明をすることとします。
• ヘッダとなるべきセルが上部以外にある場合、スクロールとフォーカスの扱いがJTableとJScrollPaneの組み合わせではややこしい。たとえば、表の左側を固定してヘッダとしたい場合、典型的な実装例ではJScrollPaneのRow Headerに別のJTableインスタンスや、JListインスタンスを設定して、データ内容や表示を同期したりします。単純な例ではそれでも良いのですが、フォーカスの移動や、スクロール、データ内容更新に伴う列サイズの更新などが生じた場合のハンドリングが複雑で、バグが生じやすく、また、再現が難しいケースもあるので実装としては避けたい方式です。
• JTableを拡張する場合、Javaバージョン追随に対して十分ケアしなければならなくなる。Java SE 6ではJTableに対してsortやDropModeなどの拡張が追加されていますが、Java SEのバージョンアップに伴って一般的なメソッド名として追加されてしまうと、のちのち重複した名前をつけてしまった場合に面倒になります。特に、一般的な名称は標準的な仕様でりようされてしまい、回避的な名称にすると、理解しづらくなってしまうので新たにクラスを起こす方が適切だろうと考えています。
• 複雑なヘッダ構造に対応できない。ヘッダとなる行（あるいは列）が複数行で構成されるような表に対応することは現状のJTableHeaderでは難しい。
• プラグイン的に振る舞いを追加することがあまり簡単ではない。表のようなコンポーネントには様々な要件が日常的に要求されますが、JTableは処理の多くを隠蔽しているので、多様な処理をあとから付け足すためにはややこしい処理を余儀なくされたり、せっかく作ってもJavaのバージョンアップとともに挙動が変わってしまう可能性もあります。

JTable継承しないデメリットもあります。JTableを含め標準的なSwingコンポーネントはLook & Feelに応じたUIレンダリングクラスが標準的に用意されています。その一方で、新たにコンポーネントを起こす場合には、各Look & Feel向けにそれらのUIレンダリングクラスを実装する必要が生じます。このことがSwingでカスタムコンポーネントが初期に想定されたほど開発されなかった原因の一つだと思います。ただ、これは今回、マルチLook & Feel対応を初期段階ではあきらめることで許容範囲内とします。余裕があれば、複数のLook & Feelに対応しても良いのですが面倒なのできっとしないと思います ;-P