新機能はConcernで。。。
いろいろ触ってるけど、AJDTまだまだって感じです。
特に、DeclareやIntertype定義はコードアシストが効かないばかりか
コンパイラ君がエラーを吐くので使い物にならない予感。
今回はかなり夢想レベル。
一ヵ月後には全然反対の事いってるかもしれない。
少なくとも多くのオブジェクト指向設計者は敵に回すかもね。
今、僕が暇なのは、前にも書いたとおりですが、
暇な人らしく、過去のプロジェクトで作ったライブラリを
整理しようとしています。
で、その後できればオープンソースとして
公開できりゃいいなぁとか考えています。
ただ、ここで一点個人的にはすんごい課題があるんです。
- できるだけ多くのプロジェクトで再利用したい（＝下位互換性を高める）
- クライアントから呼び出しやすくする＝（Tigerの言語仕様をサポートする）
この矛盾した二つの内容を同時にクリアしたいんですよ。
とりあえず、１つのインタフェース、メソッドに混在させる人はほっときましょう。
論外です。
以降手を加えるときは全てTigerでしか使えなくなってしまいます。
Tigerにバージョンアップできないプロジェクトはこっちのバージョンアップもでけません。
次の案：Tiger用のソースと、Classic用のソースを独立させる。
この方式はクライアントにとってはjarの切り替えだけですみますが、
以下の保障が結構大変だったりします。
なんかバグの元のような予感。。。
普通の人の案：オブジェクト指向的発想
オブジェクト指向的に考えれば、
こんな感じだと思うんですよ。
でも、この方式でもクライアントから見れば以下のようなデメリットがあります。
- Tigerの機能を使うためにはInterfaceForClassicでは駄目でTiger用のインタフェースにナローイングキャストをしなければならない
- クラスメソッドに対して全く無力
- プロジェクト途中でTigerに変えた場合Tiger用インタフェースとClassicインタフェースが混在する。→美しくない
↑が当たり前といえば当たり前なのですが、個人的には非常に嫌！！
てなわけで、、、
逝っちゃってる人の説：Tiger用の実装はConcernとみなす
クラス図的に書けば、
こんな感じ。
こうすることで、
- ConcernをWeavingしなければClassic用の実装
- ConcernをWeavingすればTiger用の実装
- Tiger用の実装はつまりSyntax Sugerレベルの非機能要求のはずだから、AbstractClassレベルでほぼ吸収可能なはず。
となって、
美しいなぁ。。。
と思ったりする次第です。
難点は、aspectrjt.jarが無いとTiger用の実装は動かないことですね。
これで密かにうざかったりする。JoinPoint等AspectJのライブラリを使用せずに
単にWeavingだけしたいときはaspectjrt.jar非依存にしてくれたらサイコー。
とサイコさんは思うわけです。
