ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

SpringAOPフレームワーク

2010-12-22 14:25:46 | そのほか

■SpringでAOPをやるには!
・ポイントカット:XMLにかく
  →便利なポイントカットも用意してくれているよ!

・アドバイス:インターセプタという




■ほかのAOPとの比較
・Springだと、プロキシベース,ポイントカットはBean定義ファイル、インターセプタは、Javaクラス
・しーさー、JBossは、aroundしかないお
・AspectJは、特殊な言語で書くお、バイトベースだお
 →バイトコードレベルとか、プロキシとか:ウィーブするところをさしている



■やり方の例

0.もともと、書きたいプログラムがあったとする
(MyAopDiImpl.java これ以外に、IAopDi.javaも存在する)
・インターフェースになっていないと、できない。インターフェースにしてることだいじ
package sample;

public class MyAopDiImpl implements IAopDi {
	  private String name;

	  public String getName() {
	     return name;
	  }

	  public void setName(String name) {
	     this.name = name;
	  }
}



1.インターセプションしたいクラスをかこう!
(MyBeforeAdviceInterceptor.java)

import java.lang.reflect.Method;

import org.springframework.aop.MethodBeforeAdvice;

public class MyBeforeAdviceInterceptor implements MethodBeforeAdvice {

    public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable {
      System.out.println("Hi!!");
    }



Before用にMethodBeforeAdviceみたいに、アドバイスのクラスがいろいろ用意されている

2.getBeanするところを書く
(sample.java等、mainメソッドの中)
        WebApplicationContext context = WebApplicationContextUtils
                                         .getRequiredWebApplicationContext(getServletContext());

        IAopDi obj = (IAopDi) context.getBean("myFactoryBean");
        out.println(obj.toString());



3.設定ファイルを書く
(applicationContext.xml等、設定ファイルのxml)
  <bean id="myFactoryBean" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="proxyTargetClass"><value>false</value></property>
    <property name="proxyInterfaces"><value>sample.IAopDi</value></property>
    <property name="target"><ref local="obj"/></property>
    <property name="interceptorNames"><value>myAdvisor</value></property>
  </bean>
  <bean id="myAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
    <property name="advice"><ref local="myInterceptor"/></property>
    <property name="pattern"><value>.*get.*</value></property>
  </bean>
  <bean id="myInterceptor" class="sample.MyBeforeAdviceInterceptor"/>
  <bean id="obj" class="sample.MyAopDiImpl"/>



(< >は、本当は半角)

これで、実行すると、いいらしい・・・




■Autoproxy書くと
 設定簡単!なんだって・・・



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

デザインパターンとフレームワーク

2010-12-22 10:41:03 | そのほか

 GoFのデザインパターンは、昔は実務をやっているSEさん、プログラマーさんでも、よく言われたけど、今は、「生産性向上」という文脈では、アカデミックの人はまだ使っているけど、実務の人は、そういうことは言わないと思う。

 もちろん、SE、プログラマさんでも、教養や趣味として、勉強することはあるかもしれない。
 しかし、「デザインパターンに沿ってプログラミングすると、生産性が向上したり、再利用性が向上するので、どんどん利用しましょう!」とは、言わないと思う(アカデミックでは、まじ、言うんだよ、いまだに、これ・・・)。

 その代わり、実務では、フレームワークを使って、とくに、一部(あるいは全部?)を自動化することによって、生産性向上、場合によっては再利用という話は、非常に良く聞くというより、アーキの仕事って、その選択が全てかもお・・・って思うくらい。。

 で、なぜ、そうなったのか?について、ちょっと説明したことがあったんだけど、せっかくなので、そのとき話した内容をメモメモ




■生産性向上の流れ

 生産性向上の流れから、まず、デザインパターンとフレームワークを位置づけてみたい

(1)まず、生産性向上のための手法としては、
  ・同じ処理部分を切り出す
    →同じ処理部分=共通部分をライブラリ化
 というライブラリによる手法がはじめに出た。

(2)さらに、それをメタな形にして、
   ・同じようなことをやるところを切り出す
     →同じコトをやっている=パターン

 という考えが生まれた。これは、ライブラリの場合もあるけど、
 ライブラリ以外の分野でも、パターンは考えられる。

  たとえば、将来、オブジェクトが変更されるコトが見込まれる場合、
  つまり、現在、MyClassVer1だが、数年後にはMyClassVer2になるようなとき、
  現在のクラスのメソッドは将来にもあって、そこは、互換性をとるとしたら、
  すべてのクラスをMyClassVer1からMyClassVer2に書き換えるのは面倒なので、
  MyClassというインターフェースをつくり、すべての操作は、そのMyClassで
  行って、生成部分だけ、MyClassVer1かMyClassVer2かを切り分ける。

  このようなインターフェースの使い方は、パターンであるけど、
  やり方、考え方なので、ライブラリではない。

 そして、とくに、パターンの中でも、GoFのデザインパターンが有名になった。

  パターンだと、さっきの生成部分、MyClassVer1かMyClassVer2かを切り分ける
  ところ、どうやってもいいんだけど、ただnewで書かれると、すべてのnewを
  書き換えないといけないからこまる。

  そこで、newさせないために、Factoryクラスを作成し、そのFactoryクラス
  からインスタンスを受け取り、Factoryクラスの中で、MyClassVer1か
  MyClassVer2か、どちらを生成するかを切り分けるようにすると、生成が
  局所化され、利用者は、バージョンの違いを意識しなくていいというように
  なる。これが、GoFのデザインパターンのFactoryパターン

(3)ところが、パターンの場合、なにも決まりのない、自由なところから、
 パターンを利用することになる。そうすると、パターンを利用したり、
 利用しなかったり見たいな感じで、統制がとれない。
  パターンを利用するにも、かなりの技術がいるのだ・・・

  そこで、プロジェクト全体で、統制を取る開発方法が必要になった。
  つまり、自由を規制し、「ここだけ、コーディングしてね!」という形で、
 他は、共通のノウハウを使うという、「パターンのノウハウパッケージ化」
 みたいな感じのことが必要になった。

 これを実現したのがフレームワーク。

   さっきの生成の例で言うと、生成する部分は、設定ファイルに書いて、
   生成は、getBeanでしてね・・・(SpringDI)みたいなかんじ。




■デザインパターンとフレームワークの関係

 なので、デザインパターンだと、全部自由に書けるところから、パターンを使って書くという形になる。

 フレームワークは、もう、書くところは決まっていて、そこだけ書くということになる(ハリウッドの法則)

 ということなので、フレームワーク作成者は、デザインパターンを使って、フレームワークを作るかもしれない。しかし、フレームワークが出来てしまえば、あとは、そこに何を書くかは決まっていて、それだけを書けばいい。
 フレームワークによって、書く場所が限定され、その部分の書き方が固定化できるようになったから、自動化できる可能性が広がったともいえる。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月21日(火)のつぶやき

2010-12-22 02:25:10 | Twitter
16:17 from web
「ニコニコ動画であゆ…エイベックスが音源許諾」 http://headlines.yahoo.co.jp/hl?a=20101220-00001050-yom-ent
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする