で、次。アスペクトの有効な可能性が期待できる領域。

1.メモリーが非常に狭く、オブジェクト指向の実行時オーバーヘッドが問題になる分野
　例：携帯Javaアプリ　初代i-appliは、実用的に二つまでしかクラスを使用できない、
　　　　　　　　　　　つうトンデモない事実上の実装制限があったわけで、
　　　　　　　　　　　そこでオブジェクト指向と類似したモジュールプログラミングを目指すと、
　　　　　　　　　　　アスペクトという解が出てきた。

2.設計の悪い、一体型(スパゲティ)Javaアプリケーションのカスタマイズ。
　業務アプリをとりあえず、Javaで書いたものの、全然オブジェクト指向設計じゃない、
　オブジェクト指向の保守性に関するメリットを全然享受できないやん・・・
　つうレガシー予備軍アプリの再利用検討の案件を受けて、
　アスペクト指向の適用を思いついた。(3年前。但し、シャレのわからん上司はCATENAの某手法を進めたがったので没(爆笑)

3.IDEのwizard機能とか、手製でExcelとかで書かれてる、ソースコード・ジェネレータの、進化方向としての提案
　よく似た、類型コードを、ちょっとずつ変えて大量生産する、つう事が、世間ではよく行われています。
　んで、継承で済まないのか？とよく調べて見ると、実は、初期オプション変えて自動生成したコードを元に、
　プログラマに手書きでコードを追加してもらう、いわゆる俗世間で言う「てんぷれぇと」として使ってるらしいです。
　しかし、最新のUMLモデラーのリバース機能みたく、
　変更したソースを再度読み込んで、初期オプションを変更したり、コード変更に伴うオプション変更を検出することは、
　大抵できないみたいっすね。

　よく考えると、自動生成したコードは、アスペクト指向のクロスカッティング・コンサーンなのではないか、と。
　すると、アスペクトの方をいくらでも途中で変更できるから、上記リバース機能の代替案になるのではないか、と。
　かように思うわけですが、まぁ今やってる仕事で即試す訳にもいかないし、
　誰か研究してくんないかなぁー、と、かように私は思う訳です。