2005-02-01
■ [Java][Linux]LookingGlass 動いた！
気を取り直してあちこち確認していた。lg3d-dev のスクリプトを確認したら /var/tmp/lgserver.log にログが書かれているようなので、それを確認。すると、
Require Java3d 1.3.2 later
みたいなのがあった。(もう消えちゃってて本当のメッセージは不明)
/usr/java/jdk1.5.0/jre/lib の下をみたら、Java3d のアーカイブから展開しているはずのファイルが存在しなかった。Java3d のアーカイブを展開した中に j3d-132-build8-linux-x86.jar が入ってるんだけど、これをさらに jar で展開しなきゃいけないのを忘れていたらしい。
# cd /usr/java/jdk1.5.0/jre # jar xvf java3d-1_3_2-build8-linux-i586/j3d-132-build8-linux-x86.jar
すると、LookingGlass が起動するようになった。
でも、フルスクリーンモードで LookingGlass を起動した後、LookingGlass を終了させると画面全体がストライプになってしまう。。。結局、電源長押しからは解放されなかった。
■ [OO]Template Method パターンは必要か？
そもそも Template Method パターンってのは必要ではない適用可能な場面がかなり限られている。Template Method パターンを使う場合、仕様と実装が分離できていない。仕様と実装が密結合してしまうために保守性を低下させている。
Template Method パターンの意図は、サブクラスの仕様を定義しようとするところにある。つまりインタフェースで仕様を定義すればそれですむことだったりする。例として、3つのメソッドが順に呼ばれることを期待したインタフェースを書いてみる。*1
public interface Algorithm { public void first(); public void second(); public void third(); }
仕様をインタフェースで定義するこの方法ならば柔軟性が確保できる。Template Method パターンが持つ「スーパークラスの実装に依存する」という制約を回避できる。
また、次のように、各メソッドの前に別のメソッドを追加するといった、アルゴリズムを拡張したい要求があっても容易に対応できる。
public interface ExtendedAlgorithm extends Algorithm { public void prepareFirst(); public void prepareSecond(); public void prepareThird(); }
Template Method パターンとは、インタフェースで仕様を定義し、別のクラスで実装するという理想的なモデルが縮退した(仕様と実装が結合した)特殊なケースだ。つまり、縮退させることが妥当であることを説明できる合理的な理由がなければ、Template Method パターンを使ってはいけない。
*1：例に書いたメソッドの命名は良くない。後で first() と second() の間に何かの処理を追加したくなったときに困ることになる。メソッド名はそのメソッドの目的などを表すようにするのが良い
# ray 『>そもそも Template Method パターンってのは必要ではない
必要かどうかという観点で見たらすべてのデザインパターンは必要ではないでしょう．パターンってのは適用すると有用な場面が存在する，というだけのものなのだから…
# 適用すべき場面に滅多に出逢わないパターンではありますけど
それとは別に上の例では first() second() third()がpublic
になってクライアントコードからアクセスできてしまいます．
これでは手順道理に呼ばれることを保証できません．メソッド3つ程度なら誰も間違えないでしょうが．
Algorithmがクライアントに提供すべきサービスは first() や second() や third() ではないのではないでしょうか？』
# satoshis 『確かに「必要ではない」は言いすぎですね。訂正します。
アクセスの件はpublicじゃなくてもクライアントコードから呼び出せますし、呼び出し順序はDbCの話なので、どちらもTemplateMethodの優位性はないと思いますが。。。』
# ray 『いえ…「必要ではない」が言いすぎなのではなくて，「必要ではない」のが当り前では？という話です．
#必要ってのは「必ず要る」ってことですから
必要でなないけれど有用な場面が(稀にかもしれないけど)あるでしょう．別の実装方法で置換えが可能であることを証明してもTemplate Methodパターンが有用な場面があることを否定することにはなりません．
* Template Method パターンが有用な場面すべてに適用可能
* Template Method にないメリットがある
* Template Method 以上の(実装時，実行時の)コストがかからない
というような新しいパターンを作って普及させれば継承を使った Template Method パターンを使う人が減っていくでしょう…
上で示された方法(インターフェース+委譲+DbCで呼出し順序を制御する？でいいのかな？)では継承を使った Template Method パターンより柔軟になる部分があるのは確かですがそれ以上に実装時のコストが大きくなってる気がします．加えて全てのコードに高い柔軟性が要求されるわけではありませんし…』
# t-doi 『Template Methodパターンは仕様を定義しようとしているのでしょうか？
GOF本からの抜粋------
１つのオペレーションにアルゴリズムのスケルトンを定義しておき、その中のいくつかのステップについては、サブクラスでの定義に任せることにする。
-----
Template Methodパターンはある骨格を持ったアルゴリズムのなかで、可変にしてもかまわない部分のみをサブクラスで再定義させる為のものではないでしょうか？
上記のインターフェイスを使ったTemplate MethodはもはやTemplate Methodではない気がするのですが、いかがでしょうか？』
# satoshis 『→ http://d.hatena.ne.jp/satoshis/20050202#p2
個人的には結論を出してしまいました。
「原則(特に初心者)はインタフェースを使った Strategyパターンを検討する(させる)。継承のリスクやクラス構造、トレードオフその他を考慮しても妥当ならTemplate Methodパターンを採用する」、と。』