Implementation Patternsネタ
Versioned Interface パターンが面白そうなネタでした。
「インターフェースに新規にメソッドを追加したいけど、インターフェースを変更することはできない」という状況での実装パターン。
// 当初のインターフェース interface Worker { void do(); } //--------------------------------- // 新メソッドを追加したインターフェース interface UndoWorker extends Worker{ void undo(); } //--------------------------------- // 呼び出し元 Worker worker = WorkerFactory.create(); worker.do(); // 新機能を使いたいところでだけダウンキャスト if(worker instanceof UndoWorker) { worker.undo(); }
なにかフレームワークを作って広く公布(publish)されてしまったあとにインターフェースを変更したくなった時なんか便利そうです。元のインターフェースをどこの誰がimplementsしているか把握できない状況で、既存のソースに影響を与えずにメソッドを追加できる。
毎度毎度言いっぱなしですけど、実際どれだけ活用されているかはわかりません。googleコードサーチで「versioned interface」でググッた範囲ではそれっぽいのが見つかりませんでした*1。通常のGoogle検索ではそこそこヒットするので、もう少し確認とってみる予定。
自分も使う機会があったら使ってみたいですけど、よっぽど汎用性の高いフレームワークでないとなかなかこういう状況はなさそうです。
というネタをmixiのJavaコミュで「instanceofを実践で使うか否か」という話を読んでて書いてみたくなりますた。
2008-01-22 22:55 追記
当初「使ってみたい」とか書いちゃいましたが、積極的に使うパターンではないですね。ケント・ベック氏も「複数のバージョン付きインターフェースが出てきたら、それはデザインを練り直すサインなのだ」と述べています*2。
ブチャラティの兄貴風に言うなら「新しい操作を追加する」「既存の実装も動かす」両方やらなくっちゃあならないってのがフレームワーク拡張のツラいところだなというところでしょうか。
