直掛云帆濟(jì)滄海，展翅遨翔登九天!

        從這一階段開始講述軟件設(shè)計(jì)模式，我也不再講GoF的神奇歷史，直接進(jìn)入正題。在進(jìn)行模式講解的同時(shí)，對(duì)于本人來(lái)說(shuō)，一方面也是進(jìn)行了復(fù)習(xí)，另一方面也是通過(guò)講解使自己對(duì)這些模式的使用上達(dá)到一個(gè)更加理解的層次。搞軟件的朋友都知道，在進(jìn)行開發(fā)過(guò)一段時(shí)間后，會(huì)發(fā)現(xiàn)自己大學(xué)里學(xué)習(xí)的基礎(chǔ)課很重要。而目前很多朋友對(duì)軟件的理解都非常膚淺，只知道增刪改查，試用這樣的程序員能存活多久，思考很重要，學(xué)習(xí)很重要，理解很重要，領(lǐng)悟更重要。讓浮燥的程序員回歸理性吧，模式可能讓浮燥的心情得到凈化，在模式中進(jìn)行思考，在模式中進(jìn)行領(lǐng)悟吧。
        第一講是裝飾器。當(dāng)初我在學(xué)裝飾器模式的時(shí)候總是感覺似懂非懂，一直沒有真正理解。其實(shí)裝飾器也叫油漆工模式，再加上在我們的java類庫(kù)中有很多是實(shí)現(xiàn)了裝飾器模式的類。比方說(shuō)：在讀取文件時(shí)
FileReader fr = new FileReader(filename);
BufferedReader br = new BufferedReader(fr);
這其實(shí)就是一個(gè)decorator模式。因?yàn)獒槍?duì)File的讀取方式有很多，如果每種都要采用繼承的方法，那么會(huì)產(chǎn)生很多的子類，那樣顯然是很煩的。
          裝飾器也稱為油漆工模式。它的目的就是給一個(gè)對(duì)象動(dòng)態(tài)地添加一些功能。就像是給對(duì)象刷了一層漆，使這個(gè)對(duì)象更加豐富，而不是通過(guò)繼承來(lái)增加功能。而這些功能的添加是動(dòng)態(tài)的運(yùn)行期的，當(dāng)然這里的動(dòng)態(tài)并不是像aop中的引介introductor，大家不要混淆。
          在我們的項(xiàng)目中，經(jīng)常會(huì)遇到日志的情況。大凡我們會(huì)定義一個(gè)log接口就像下面。
public interface Logger {
    public void log(String msg);
}
一般我們會(huì)把日志保存中文件中，所以有了一個(gè)FileLogger

public class FileLogger implements Logger {

 public void log(String msg) {
        //開始記錄日志到文件中
 }
}
此時(shí)如果在項(xiàng)目有些地方需要對(duì)日志進(jìn)行加密，有些地方又不需要加密，或者有些地方生成的文件是以xml的方式。此時(shí)如果采用繼承的方法，也能實(shí)現(xiàn)，但是從面向?qū)ο蟮慕嵌葋?lái)說(shuō)，并不建議對(duì)象的層次太深，增加系統(tǒng)的復(fù)雜性，這樣對(duì)于系統(tǒng)的擴(kuò)展和維護(hù)都不是很方便。此時(shí)Decorator模式就可以幫我們解決這些問(wèn)題，我們可以為這個(gè)一般的FileLogger對(duì)象上刷一層不同的漆，那么這些漆，從上面增加的功能角度來(lái)說(shuō)，就是加了一個(gè)“加密”的漆，或加了一層“生成xml”的漆。
先定義一個(gè)Decorator接口，此接口也實(shí)現(xiàn)了Logger接口
public class LoggerDecorator implements Logger{
   Logger logger;
   public LoggerDecorator(Logger logger){
        this.logger=logger;
   }
   //開始記錄日志
   public void log(String msg){
       //此處便是給實(shí)現(xiàn)了Logger接口的，被刷了油漆的(增加了功能的例如加密等)對(duì)象記錄日志
       logger.log(msg);
   }
}
public class EncryptDecorator extends LoggerDecorator{
    public EncryptDecorator(Logger logger){
        super(logger);
    }
    public void log(String msg){
        //刷加密字符串的油漆
        msg=this.encryptMsg(msg);
        //記錄加密后的日志
        logger.log(msg);
    }
}
//客戶端的調(diào)用
public DecoratorClient{
    public static void main(String args[]){
         Logger logger=new FileLogger();
         Logger decorator=new EncryptDecorator(logger);
         decorator.log("加密的字符串");
   }
}
這樣就基本把Decorator模式的應(yīng)用起來(lái)，當(dāng)然在項(xiàng)目中我們可能還需要更豐富一下我們的類，此處僅用這樣的簡(jiǎn)單示例來(lái)講述。

         網(wǎng)上google一下，想找一些有用的資料，結(jié)果是搜了不少，誰(shuí)知道都是轉(zhuǎn)載，而且相同的文章太多太多，達(dá)到了泛濫的地步，然后冒充自己的文章，也不提是轉(zhuǎn)載，貌似增加了網(wǎng)絡(luò)搜索資料的途徑，實(shí)是浪費(fèi)真正想找資料的朋友的時(shí)間，殊不知?jiǎng)e人的時(shí)間都是有限的，每次打開一個(gè)頁(yè)面結(jié)果卻都是相同的內(nèi)容，你叫人氣不氣，擾亂了整個(gè)網(wǎng)絡(luò)的制序，損人利己，濫宇充數(shù)。
    網(wǎng)上的資料不是不可轉(zhuǎn)載，但請(qǐng)轉(zhuǎn)載者在盲目轉(zhuǎn)載的同時(shí)，請(qǐng)?zhí)岢鲎约旱目捶ㄒ庖姡粝掠杏玫男畔ⅲ駝t亂貼在自己的blog只會(huì)讓真正的有志之士所看不起，如果您無(wú)法原創(chuàng)，就請(qǐng)您把您的blog關(guān)閉。
    清除網(wǎng)絡(luò)垃圾，還我們一片干凈的網(wǎng)絡(luò)空間!!!

        Java中有關(guān)數(shù)據(jù)結(jié)構(gòu)的類都在java.util包中，集合框架是每一個(gè)程序員都應(yīng)該熟練掌握的一個(gè)類庫(kù)。Java的集合框架可以提供處理對(duì)象的標(biāo)準(zhǔn)方式。在很早的jdk版本中，只提供了Dictionary、Vector、Stack、Properties來(lái)存儲(chǔ)和操作對(duì)象。這些類之間沒有統(tǒng)一的api，使用這些類達(dá)不到易擴(kuò)展的作用。
        當(dāng)然我們使用這些數(shù)據(jù)結(jié)構(gòu)目的也是為了使用方便，能夠提供高效的存取。學(xué)過(guò)數(shù)據(jù)結(jié)構(gòu)的朋友們都知道，鏈表和哈希表的結(jié)構(gòu)的效率都是較高的。為了使用不同的集合之間能夠相互操作，相互擴(kuò)展，那么使用通用的接口將是一個(gè)較好的選擇。所以整個(gè)集合框架被設(shè)計(jì)成了一系列的標(biāo)準(zhǔn)的接口。在Collections類中有許多靜態(tài)的算法方法。Iterator迭代器接口提供了通用的訪問(wèn)集合元素的方式，因?yàn)槊恳粋€(gè)集合都實(shí)現(xiàn)了Iterator接口。除了集合，還提供了映射的接口和類。比方說(shuō)Map就提供了存儲(chǔ)鍵值對(duì)。雖然它不是集合，但也被整合到了集合中。目前所有的集合都是基于泛型的。
        下面介紹集合框架中的幾個(gè)常用的接口：
1.Collection 允許處理一組對(duì)象，位于集合層次結(jié)構(gòu)的頂部
2.List  擴(kuò)展Collection接口以處理序列
3.Queue  擴(kuò)展Collection接口以處理列表中的特殊類型，其元素只能從前面刪除
4.Set  擴(kuò)展Collection接口以處理集合，集合中的元素必須是唯一的
5.SortedSet  擴(kuò)展Set接口以處理排序的集合
當(dāng)然除了上述的接口外，集合中還使用Copmarator、Iterator、ListIterator等接口 。
        Collection接口是構(gòu)造集合框架的基礎(chǔ)，必須被定義集合的任意類實(shí)現(xiàn)，同樣它也是一個(gè)泛型接口。

方法摘要
boolean	add(E o)           確保此 collection 包含指定的元素（可選操作）。
boolean	addAll(Collection<? extends E> c)           將指定 collection 中的所有元素都添加到此 collection 中（可選操作）。
void	clear()           移除此 collection 中的所有元素（可選操作）。
boolean	contains(Object o)           如果此 collection 包含指定的元素，則返回 true。
boolean	containsAll(Collection<?> c)           如果此 collection 包含指定 collection 中的所有元素，則返回 true。
boolean	equals(Object o)           比較此 collection 與指定對(duì)象是否相等。
int	hashCode()           返回此 collection 的哈希碼值。
boolean	isEmpty()           如果此 collection 不包含元素，則返回 true。
Iterator<E>	iterator()           返回在此 collection 的元素上進(jìn)行迭代的迭代器。
boolean	remove(Object o)           從此 collection 中移除指定元素的單個(gè)實(shí)例，如果存在的話（可選操作）。
boolean	removeAll(Collection<?> c)           移除此 collection 中那些也包含在指定 collection 中的所有元素（可選操作）。
boolean	retainAll(Collection<?> c)           僅保留此 collection 中那些也包含在指定 collection 的元素（可選操作）。
int	size()           返回此 collection 中的元素?cái)?shù)。
Object[]	toArray()           返回包含此 collection 中所有元素的數(shù)組。
<T> T[]	toArray(T[] a)           返回包含此 collection 中所有元素的數(shù)組；返回?cái)?shù)組的運(yùn)行時(shí)類型與指定數(shù)組的運(yùn)行時(shí)類型相同。

List接口：
該接口擴(kuò)展了Collection接口，它聲明集合是存儲(chǔ)一個(gè)序列的元素。我們可以把它看成是動(dòng)態(tài)數(shù)組。學(xué)過(guò)數(shù)據(jù)結(jié)構(gòu)的朋友都知道，數(shù)組可以使用基于0的索引，對(duì)于泛型的List接口而言，他可以指定保存不同的對(duì)象類型。

方法摘要
boolean	add(E o)           向列表的尾部追加指定的元素（可選操作）。
void	add(int index, E element)           在列表的指定位置插入指定元素（可選操作）。
boolean	addAll(Collection<? extends E> c)           追加指定 collection 中的所有元素到此列表的結(jié)尾，順序是指定 collection 的迭代器返回這些元素的順序（可選操作）。
boolean	addAll(int index, Collection<? extends E> c)           將指定 collection 中的所有元素都插入到列表中的指定位置（可選操作）。
void	clear()           從列表中移除所有元素（可選操作）。
boolean	contains(Object o)           如果列表包含指定的元素，則返回 true。
boolean	containsAll(Collection<?> c)           如果列表包含指定 collection 的所有元素，則返回 true。
boolean	equals(Object o)           比較指定的對(duì)象與列表是否相等。
E	get(int index)           返回列表中指定位置的元素。
int	hashCode()           返回列表的哈希碼值。
int	indexOf(Object o)           返回列表中首次出現(xiàn)指定元素的索引，如果列表不包含此元素，則返回 -1。
boolean	isEmpty()           如果列表不包含元素，則返回 true。
Iterator<E>	iterator()           返回以正確順序在列表的元素上進(jìn)行迭代的迭代器。
int	lastIndexOf(Object o)           返回列表中最后出現(xiàn)指定元素的索引，如果列表不包含此元素，則返回 -1。
ListIterator<E>	listIterator()           返回列表中元素的列表迭代器（以正確的順序）。
ListIterator<E>	listIterator(int index)           返回列表中元素的列表迭代器（以正確的順序），從列表的指定位置開始。
E	remove(int index)           移除列表中指定位置的元素（可選操作）。
boolean	remove(Object o)           移除列表中出現(xiàn)的首個(gè)指定元素（可選操作）。
boolean	removeAll(Collection<?> c)           從列表中移除指定 collection 中包含的所有元素（可選操作）。
boolean	retainAll(Collection<?> c)           僅在列表中保留指定 collection 中所包含的元素（可選操作）。
E	set(int index, E element)           用指定元素替換列表中指定位置的元素（可選操作）。
int	size()           返回列表中的元素?cái)?shù)。
List<E>	subList(int fromIndex, int toIndex)           返回列表中指定的 fromIndex（包括 ）和 toIndex（不包括）之間的部分視圖。
Object[]	toArray()           返回以正確順序包含列表中的所有元素的數(shù)組。
<T> T[]	toArray(T[] a)           返回以正確順序包含列表中所有元素的數(shù)組；返回?cái)?shù)組的運(yùn)行時(shí)類型是指定數(shù)組的運(yùn)行時(shí)類型。

相對(duì)于Collection接口而言，List接口增加了add(int index, E element),add(int index,Collection c)方法，這些方法用于將元素插入到特定的位置，這也是動(dòng)態(tài)數(shù)組的特性。
Set接口：
該接口擴(kuò)展了Collection接口，但不允許有相同的存在的元素，而上述的List接口卻沒有此約束，其實(shí)很好理解，我們可以把它想象成數(shù)學(xué)中的集合，在那種集合中，是不允許有相同的元素的。
SortedSet接口擴(kuò)展了Set接口，此接口是升序的集合，由于是有序的，所有自然其中的數(shù)據(jù)元素是有意義的，否則升序的算法無(wú)從使用起。自然就不能存在為null的對(duì)象。下表是該接口特有的方法：

方法摘要
Comparator<? super E>	comparator()           返回與此有序集合關(guān)聯(lián)的比較器，如果使用元素的自然順序，則返回 null。
E	first()           返回此有序集合中當(dāng)前第一個(gè)（最小的）元素。
SortedSet<E>	headSet(E toElement)           返回此有序集合的部分視圖，其元素嚴(yán)格小于 toElement。
E	last()           返回此有序集合中最后一個(gè)（最大的）元素。
SortedSet<E>	subSet(E fromElement, E toElement)           返回此有序集合的部分視圖，元素范圍從 fromElement（包括）到 toElement（不包括）。
SortedSet<E>	tailSet(E fromElement)           返回此有序集合的部分視圖，其元素大于或等于 fromElement。

Queue接口：
這個(gè)接口在1.4的版本中是沒有，新增的。看名字就知道是隊(duì)列，先進(jìn)先出。

方法摘要
E	element()           檢索，但是不移除此隊(duì)列的頭。
boolean	offer(E o)           如果可能，將指定的元素插入此隊(duì)列。
E	peek()           檢索，但是不移除此隊(duì)列的頭，如果此隊(duì)列為空，則返回 null。
E	poll()           檢索并移除此隊(duì)列的頭，如果此隊(duì)列為空，則返回 null。
E	remove()           檢索并移除此隊(duì)列的頭。

從隊(duì)列頂部刪除元素 。

        AOP全稱叫做Aspect-Oriented Programming，即面向方面編程或叫做面向切面編程。目前基于java的開源框架有很多已經(jīng)應(yīng)用了AOP思想進(jìn)行設(shè)計(jì)開發(fā)。在輕量級(jí)的J2EE應(yīng)用開發(fā)中，AOP經(jīng)常可以解決一些系統(tǒng)級(jí)的服務(wù)，比方說(shuō)事務(wù)處理、安全檢查、系統(tǒng)日志等。
        目前在AOP編程開發(fā)中，有許多新的名詞，這些名詞的出現(xiàn)會(huì)讓一些剛開始涉足AOP的朋友們是一頭霧水。下面我會(huì)把每個(gè)名詞的意思用自己的語(yǔ)言再描述一遍。
        關(guān)注點(diǎn)：關(guān)注點(diǎn)即是需要我們?nèi)ソ鉀Q的去關(guān)心的問(wèn)題。關(guān)注點(diǎn)又可分為核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。核心關(guān)注點(diǎn)指的是一個(gè)系統(tǒng)中的核心業(yè)務(wù)功能，也可以認(rèn)為是是業(yè)務(wù)邏輯。橫切關(guān)注點(diǎn)指的是充斥在各個(gè)核心關(guān)注點(diǎn)間的可以解決同一類問(wèn)題的的關(guān)注點(diǎn)。那么我們的系統(tǒng)也可以認(rèn)為是由若干個(gè)關(guān)注點(diǎn)組成的。
       連接點(diǎn)：連接點(diǎn)就是在程序運(yùn)行時(shí)需要在某一點(diǎn)中插入切面，那一點(diǎn)就是連接點(diǎn)。這一點(diǎn)可以是一個(gè)方法、一個(gè)屬性、構(gòu)造函數(shù)、類靜態(tài)初始化模塊。在Spring框架中，只關(guān)注方法的切面，即只關(guān)心的是方法連接點(diǎn)。
        切入點(diǎn)：切入點(diǎn)其實(shí)就是連接點(diǎn)的集合。在Spring框架中我們經(jīng)常可以看到利用正則表達(dá)式對(duì)切入點(diǎn)進(jìn)行定義。
        通知：通知其實(shí)就是一個(gè)切面的具體實(shí)現(xiàn)。比方說(shuō)在一個(gè)業(yè)務(wù)訂單的處理中，切入了訂單處理的日志，那么這個(gè)日志的具體實(shí)現(xiàn)就是一個(gè)advice。比方說(shuō)這個(gè)日志實(shí)現(xiàn)了某人某時(shí)間進(jìn)行訂單的處理審批。那么通知有幾種。有前通知、后通知、環(huán)繞通知、當(dāng)然Spring框架中還有Exception通知。
        切面：上面講到的切入點(diǎn)與通知就是切面的組成部分。
        引介：引介很強(qiáng)大，但是目前用的比較少。它可以強(qiáng)大到給一個(gè)定義好的類在運(yùn)行時(shí)動(dòng)態(tài)地添加方法、屬性。
        織入：光有切面與核心關(guān)注點(diǎn)是不夠的，因?yàn)檫@樣兩者還沒有建立關(guān)系起來(lái)。那么織入的目的就是讓兩者建立起關(guān)系。織入也有三種方式：
1.通過(guò)Java代理實(shí)現(xiàn)織入。那么又有兩種方式。一種是基于代理接口的Java動(dòng)態(tài)代理。另一種是動(dòng)態(tài)字節(jié)碼生成器代理，也就是在spring中的經(jīng)常發(fā)現(xiàn)的cglib.jar包。
2.有些Aop的實(shí)現(xiàn)織入采用了自定義的類加載器，在虛擬機(jī)加載字節(jié)碼的時(shí)候進(jìn)行織入。
3.最后一種就是使用專門的編譯器來(lái)編譯整個(gè)應(yīng)用程序，在編譯的過(guò)程中就進(jìn)行織入。
        攔截器：攔截器故名思意就是進(jìn)行攔截。它可以對(duì)連接點(diǎn)進(jìn)行攔截。那么攔截器也可以組成鏈通常也稱為棧。攔截器的說(shuō)明可見我上一篇文章。
       
       
未完待續(xù)!

     摘要:         本文為本人翻譯struts2的官方網(wǎng)站上的關(guān)于攔截器的說(shuō)明文檔，官方網(wǎng)站上的說(shuō)明均是英文的，不方便熱愛學(xué)習(xí)而英語(yǔ)又不太好的朋友。該說(shuō)明文檔地址是http://struts.apache.org/2.0.11/docs/interceptors.html。     &nbs...  閱讀全文

        Unified Modeling Language 的出現(xiàn)給當(dāng)今面向?qū)ο蟮氖澜缭鎏砹藵饽实囊还P。可視化的建模工具讓開發(fā)人員豐富地表達(dá)了他們的想象力，并且以u(píng)ml的方式向其他人展示。
        首先我們得理解什么是面向?qū)ο?Object Oriented)。對(duì)象是各種各樣的實(shí)體，即是具體的事物也是抽象的事物。面向?qū)ο蟛还馐菍?duì)對(duì)象的屬性和行為建模，它還包括其它方面。其中就有抽象、繼承、多態(tài)和封裝。抽象的概念很抽象，其意思是說(shuō)抽象出你所需求的屬性和操作，即是所需的東西。它是一種從一般的觀點(diǎn)看事物的方法，焦點(diǎn)應(yīng)該集中在事物的本質(zhì)性質(zhì)上，而不要過(guò)分地去追求細(xì)節(jié)，應(yīng)該是抽象出一般化的東西。世界是復(fù)雜的，但不能因?yàn)樗鼜?fù)雜就不去理解它，我們可以把它抽象化，其實(shí)抽象后世界也不大。
         繼承：顧名思意就是子類擁有父類的所有的內(nèi)部狀態(tài)和運(yùn)動(dòng)規(guī)律。公共的東西可以被子類分享，正所謂，子又有孫，孫又有子，子子孫孫無(wú)窮潰也。當(dāng)然不能像這樣來(lái)設(shè)計(jì)。
         多態(tài)：多個(gè)形態(tài)，同樣的一種動(dòng)作，在不同的對(duì)象進(jìn)行演繹的時(shí)候可能演繹的細(xì)節(jié)就會(huì)不一樣。正所謂大家都喜歡吃，但是男人吃飯跟女人吃飯就不一樣。男的可能吃的快吃的多，女的吃的少吃的慢，但大家都是吃這個(gè)動(dòng)作，換了個(gè)對(duì)象來(lái)吃，就效果不一樣。
         封裝：舉個(gè)例子，人們?cè)诳措娨晻r(shí)，人們看到的是電視的屏幕，電視的按鈕，至于屏幕為什么上面會(huì)有美女，按下按鈕為什么會(huì)換臺(tái)，人們好象不必去關(guān)心其是怎么工作的吧，當(dāng)然也有閑人喜歡鉆牛角尖。所以電視機(jī)就封裝了如何讓屏幕顯示美女的工作。那么電視機(jī)的按鈕和屏幕實(shí)際上就是電視機(jī)給我們這些喜歡看電視的人的接口。我們關(guān)心的也只是這些接口。至于這些接口怎么實(shí)現(xiàn)的，請(qǐng)交給廠家吧，世界也就是由若干個(gè)各司其職的人組成的。
          重載：說(shuō)白了就是做同一件事的幾種不同的方案。比方說(shuō)：在公司加班，正常情況下，默認(rèn)是吃盒飯，有一天老板歸來(lái)，來(lái)一句走出去吃飯我請(qǐng)。如果用方法來(lái)表示的話就是public void eat(盒飯類 a) public void eat(飯店類a ,老板類b )。
          消息傳遞：在這個(gè)世界里，光有對(duì)象是不夠的，那樣人都是行尸走肉。對(duì)象之間是要相互協(xié)作的。那么相互協(xié)作之間是通過(guò)相互發(fā)送消息的方式。比方說(shuō)看電視，我們使用遙控器打開電視。那么遙控器對(duì)象就向電視機(jī)對(duì)象發(fā)送了一個(gè)開機(jī)的消息。電視機(jī)對(duì)象接收了此消息后就打開了。
          正如世界是一個(gè)由若干個(gè)對(duì)象以及對(duì)象之間的若干個(gè)錯(cuò)綜復(fù)雜的關(guān)系組成的。那么對(duì)象與對(duì)象之間又會(huì)有什么樣的關(guān)系呢？打開電視時(shí)，我們說(shuō)是你和電視機(jī)之間發(fā)了關(guān)聯(lián)關(guān)系。再比方說(shuō)你暗戀一個(gè)女生，你跟她之間形成了一個(gè)單向的關(guān)聯(lián)關(guān)系。因?yàn)樗恢滥惆祽偎?dāng)然你暗戀她，她也暗戀你的情況也有可能出現(xiàn)，此處我們不予探討。如果她也暗戀你，那就是一個(gè)雙向的關(guān)聯(lián)關(guān)系。對(duì)象之間的依賴關(guān)系說(shuō)明是目標(biāo)對(duì)象與源對(duì)象之間的依賴關(guān)系。依賴就是當(dāng)目標(biāo)對(duì)象有所變化的時(shí)候源對(duì)象也相應(yīng)的發(fā)生改變。
        收集系統(tǒng)需求時(shí)，把用戶的業(yè)務(wù)需求轉(zhuǎn)換成開發(fā)人員能夠理解的需求，并最終把需求轉(zhuǎn)化為代碼。通過(guò)將需求映射為代碼，可以保證代碼滿足這些需求，同時(shí)代碼也可以回溯成需求。這樣的過(guò)程就稱為建模。建模過(guò)程的結(jié)果可以跟蹤業(yè)務(wù)需求，到要求、到模型，到代碼的全過(guò)程及其相反的過(guò)程，而不會(huì)在這個(gè)過(guò)程中迷路。
        可視化建模將模型中的信息用標(biāo)準(zhǔn)的圖形元素直觀的表示。這個(gè)標(biāo)準(zhǔn)的圖形元素就是本文中提到的UML。它的出現(xiàn)為用戶、開發(fā)人員、分析人員、測(cè)試人員、管理人員、需求調(diào)研人員等相關(guān)人員提供了溝通的橋梁。其中很直觀的例子：對(duì)于用戶來(lái)說(shuō)，他更關(guān)心自己需要在這個(gè)系統(tǒng)中操作什么，以及這些操作是否滿足了自己的業(yè)務(wù)需要，那么利用模型他可以直觀的看到自己與這個(gè)系統(tǒng)的交互，根據(jù)這樣的交互保證需求的獲取。對(duì)于分析人員來(lái)說(shuō)，他需要分析模型的對(duì)象之間的交互，以及這樣的交互是否滿足系統(tǒng)的需要，是否可以保證這樣的交互對(duì)于業(yè)務(wù)的解析，解決自己分析時(shí)存在的疑惑，同時(shí)也可以根據(jù)模型交互的結(jié)果向需求調(diào)研人員提出問(wèn)題。對(duì)于開發(fā)人員來(lái)說(shuō)，他要考慮開發(fā)的對(duì)象以及這些開發(fā)對(duì)象需要完成的工作。對(duì)于測(cè)試人員來(lái)說(shuō)，他們根據(jù)模型看到對(duì)象間的交互并且根據(jù)這些交互以及交互的產(chǎn)出準(zhǔn)備測(cè)試用例。在RUP中就可以同步地進(jìn)行測(cè)試了，而不是像瀑布模型那樣最后才準(zhǔn)備測(cè)試。對(duì)于項(xiàng)目管理人員來(lái)說(shuō)，他需要看到系統(tǒng)中各個(gè)部分或者子系統(tǒng)之間的交互，在項(xiàng)目的實(shí)施過(guò)程根據(jù)計(jì)劃看到各個(gè)系統(tǒng)模型完成的情況及相應(yīng)的進(jìn)度。對(duì)于公司的主管人員來(lái)說(shuō)可能只需要看到更高層的模型，看到各個(gè)子系統(tǒng)運(yùn)行情況結(jié)果。可視化的建模確實(shí)帶來(lái)了系統(tǒng)的可控。通過(guò)先建模再編寫代碼，從一開始就保證了系統(tǒng)的結(jié)構(gòu)合理。利用模型可以更方便地捕獲設(shè)計(jì)缺陷，從而以較低的成本修正這些缺陷。
        Rational Rose是分析和設(shè)計(jì)面向?qū)ο筌浖到y(tǒng)的強(qiáng)大的可視化工具，可以用來(lái)先建模系統(tǒng)再編寫代碼，支持業(yè)務(wù)模型，幫助了解系統(tǒng)的業(yè)務(wù)，有助于系統(tǒng)分析，可以先設(shè)計(jì)使用案例和Use Case框圖，顯示系統(tǒng)的功能。也可以用Interaction框圖顯示對(duì)象之間如何配合，提供所需的功能。Calss框圖可以顯示系統(tǒng)中對(duì)象及其相互關(guān)系。Component框圖可以演示類如何映射到實(shí)現(xiàn)組件。最后Deployment框圖可以顯示系統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)。Rose模型的四個(gè)社圖是：Use Case視圖、Logical視圖、Component視圖和Deployment視圖。每個(gè)視圖針對(duì)不同對(duì)象，具有不同的用途。
        Use Case視圖包括系統(tǒng)中的所有角色、使用案例和Use Case框圖，還包括一些Sequence或Collaboration框圖。該視圖是系統(tǒng)中與實(shí)現(xiàn)無(wú)關(guān)的視圖。該視圖關(guān)注系統(tǒng)功能的高層形狀，而不關(guān)注系統(tǒng)具體的實(shí)現(xiàn)方法。項(xiàng)目開始時(shí)，開發(fā)小組可以選擇使用Use Case視圖中生成業(yè)務(wù)模型，完成了業(yè)務(wù)模型后便是使用案例模型。客戶、分析人員和項(xiàng)目經(jīng)理利用使用案例、Use Case框圖和使用案例文檔來(lái)確定系統(tǒng)的高層視圖。隨著項(xiàng)目的進(jìn)行，開發(fā)小組的成員也可以通過(guò)Use Case視圖了解正在建立的系統(tǒng)的使用案例文檔，通過(guò)使用案例描述事件流程。利用Use Case視圖，測(cè)試人員開始編寫測(cè)試腳本，技術(shù)人員開始編寫文檔。一旦用戶同意了角色和使用案例，就確定了系統(tǒng)的范圍。然后可以在Logical視圖中繼續(xù)開發(fā)，關(guān)注系統(tǒng)如何實(shí)現(xiàn)使用案例中提出的功能。
        Logical視圖，關(guān)注系統(tǒng)如何實(shí)現(xiàn)使用案例中提出的功能。提供系統(tǒng)的詳細(xì)圖形，描述組件間如何關(guān)聯(lián)，還包括特定的類、Class框圖和StateChart框圖，利用這些元素，開發(fā)人員可以構(gòu)造出系統(tǒng)的詳細(xì)設(shè)計(jì)。該視圖關(guān)注的是系統(tǒng)的邏輯結(jié)構(gòu)，在這個(gè)視圖中，要標(biāo)識(shí)系統(tǒng)組件，檢查系統(tǒng)的信息和功能，檢查組件之間的關(guān)系。
        Component視圖，包括模型代碼庫(kù)，可執(zhí)行文件，運(yùn)行庫(kù)和其他組件的信息。系統(tǒng)的Component視圖可以顯示代碼模塊間的關(guān)系。詳細(xì)包括：組件，代碼的實(shí)際模塊；Component框圖，顯示組件及其相互關(guān)系；包，相關(guān)組件的組。該視圖的主要用戶是控制代碼和編譯部署應(yīng)用程序的人。有些組件是代碼庫(kù)，有些是運(yùn)行組件。
        Deployment視.圖，關(guān)注于系統(tǒng)的實(shí)際部署。還包括容錯(cuò)，網(wǎng)絡(luò)帶寬，故障恢復(fù)和響應(yīng)時(shí)間等。詳細(xì)包括：進(jìn)程，是在自己的內(nèi)存空間執(zhí)行的線程；處理器，任何有處理功能的機(jī)器；設(shè)備，包括任何沒有處理功能的機(jī)器，如打印機(jī)。
        下面討論UML以及UML的可視化工具給我們帶來(lái)了什么樣的好處。rose建立的業(yè)務(wù)模型關(guān)注系統(tǒng)針對(duì)的業(yè)務(wù)。業(yè)務(wù)模型包括：業(yè)務(wù)角色、業(yè)務(wù)用例、業(yè)務(wù)工人。業(yè)務(wù)模型研究的是業(yè)務(wù)的機(jī)構(gòu)以及機(jī)構(gòu)的角色。在建立業(yè)務(wù)模型的過(guò)程中，檢查機(jī)構(gòu)的結(jié)構(gòu)和機(jī)構(gòu)中的角色以及它們之間的相互關(guān)系，還需要介紹機(jī)構(gòu)的工作流，公司中的主要過(guò)程，以及這些過(guò)程如何的工作，效率如何，是否有任何的瓶頸。簡(jiǎn)要的說(shuō)就是要弄清楚業(yè)務(wù)的內(nèi)部和外部，以及內(nèi)外部如何進(jìn)行通信。那么這些信息都將被記錄在業(yè)務(wù)模型中。業(yè)務(wù)模型中框圖有助于外部世界和機(jī)構(gòu)的關(guān)系，以及機(jī)構(gòu)如何完成這些目標(biāo)。業(yè)務(wù)模型的主要工具之一是工作流框圖。這些框圖描述機(jī)構(gòu)中的特定過(guò)程流程；顯示這個(gè)過(guò)程中參與的人員，這個(gè)過(guò)程的步驟和參與這個(gè)過(guò)程的業(yè)務(wù)實(shí)體。業(yè)務(wù)過(guò)程建模人員首先用工作流框圖建模當(dāng)前過(guò)程，然后可以分析這些框圖，尋找工作流中的缺陷和其他問(wèn)題。完成業(yè)務(wù)模型的好處在于開始規(guī)劃系統(tǒng)工作之前就完全了解了業(yè)務(wù)過(guò)程，這樣就可以事先確定最需要自動(dòng)化的工作流領(lǐng)域和系統(tǒng)中最有助于機(jī)構(gòu)開發(fā)的部分從而建立對(duì)公司或者機(jī)構(gòu)最有利的系統(tǒng)。
        實(shí)體類：實(shí)體類是要永久保存的信息。實(shí)體類通常在事件流和Interaction框圖中，是對(duì)用戶最有意義的類，通常用業(yè)務(wù)域術(shù)語(yǔ)來(lái)命名。邊界類：邊界類位于系統(tǒng)與外界的交界處，包括所以窗體、報(bào)表、打印機(jī)和掃描儀等硬件的接口以及與其他系統(tǒng)的接口。要尋找和定義邊界類，可以檢查Use Case框圖。每個(gè)角色／用例 交互至少要有一個(gè)邊界類。控制類：控制類負(fù)責(zé)協(xié)調(diào)其它類的工作。每個(gè)用例通常都有一個(gè)控制類，控制用例中的事件的順序。在Interaction框圖中，控制類具有協(xié)調(diào)責(zé)任。
       
 



















        
       

在Spring的applicationContext.xml中配置映射文件的方法：
1。減少配置文件里配置信息的數(shù)量
配置applicationContext.xml或者分布在其它的xml文件中的bean時(shí)，設(shè)置bean與bean之間的相互依賴關(guān)系是一件痛苦且容易出錯(cuò)的事。autowire屬性的出現(xiàn)減輕了配置文件的容量。
<bean>的autowire屬性有6個(gè)值。分別為：

a No：即不啟用自動(dòng)裝配。Autowire默認(rèn)的值。

b byName：通過(guò)屬性的名字的方式查找JavaBean依賴的對(duì)象并為其注入。
c byType：通過(guò)屬性的類型查找JavaBean依賴的對(duì)象并為其注入。
d constructor：通byType一樣，也是通過(guò)類型查找依賴對(duì)象。
e autodetect：在byType和constructor之間自動(dòng)的選擇注入方式。
f default：由上級(jí)標(biāo)簽<beans>的default-autowire屬性確定。
在<beans default-autowire="byName">可以為本xml文件設(shè)置默認(rèn)的自動(dòng)裝配的類型例如byName，當(dāng)然在設(shè)置具體的<bean id="***" class="***" autowire="byType">時(shí)，會(huì)自動(dòng)改變默認(rèn)的byName為byType。
2。在web.xml中通過(guò)配置如下參數(shù)

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath*:spring/*.xml</param-value>
    </context-param>   
會(huì)自動(dòng)把WEB-INF/classes/sring目錄下的所有以.xml結(jié)尾的文件加載spring容器進(jìn)行管理，而不必手動(dòng)編寫每個(gè)applicationContex.xml,accessContext.xml等配置文件。
3。利用屬性為mappingDirectoryLocation來(lái)配置相關(guān)的目錄位置，從而避免為該目錄下的所有文件名進(jìn)行配置
<property name="mappingDirectoryLocation">
<list>
<value>classpath:/package1/<value>
</list>
</property>
如：
<!-- 設(shè)置Hibernate3的SessionFactory -->
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <property name="dataSource">
            <ref bean="dataSource"/>
        </property>
        <property name="hibernateProperties">
            <props>
                <prop key="hibernate.dialect">net.sf.hibernate.dialect.SQLServerDialect</prop>
                <prop key="hibernate.show_sql">true</prop>
                <prop key="hibernate.generate_statistics">true</prop>
                <prop key="hibernate.connection.release_mode">auto</prop>
                <prop key="hibernate.autoReconnect">true</prop>
            </props>
        </property>
        <property name="mappingDirectoryLocations">       
            <list>      
               <value>classpath:com/apache/model</value>      
            </list>
        </property>   
    </bean>
4。消除ProxyFactoryBean的繁重配置
a.通過(guò)繼承于parent ProxyFactoryBean
b.使用aop自動(dòng)代理的方式
在Spring中進(jìn)行事務(wù)的管理均是基于aop的方式，為每個(gè)需要事務(wù)管理的bean均設(shè)定相應(yīng)的ProxyFactoryBean又是一件非常繁重的工作。使用自動(dòng)代理可以消除這樣的重復(fù)的工作。方法如下，聲明DefaultAdvisorAutoProxyCreator為所有的advisor作為代理，在context上下文中查找所有的advisor，然后自動(dòng)代理那些被在pointcut加入了切面的bean。針對(duì)事務(wù)使用spring中的事務(wù)的advisor,TransactionAttributeSourceAdvisor。
該advisor有兩種方式進(jìn)行注入，一種是setter方式，如下：
    <!-- 配置自動(dòng)代理事務(wù) -->
    <bean id="transactionAdvisor" class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
        <property name="transactionInterceptor" ref="transactionInterceptor"/>
    </bean>
另一種是constructor方式，如下：
    <!-- 配置自動(dòng)代理事務(wù) -->
    <bean id="transactionAdvisor" class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
     <constructor-arg>
        <ref bean="transactionInterceptor"/>
     </constructor-arg>        
    </bean>
建議以constructor方式進(jìn)行注入。

 

系統(tǒng)實(shí)現(xiàn)規(guī)范：以面向接口的方式進(jìn)行編程。
下圖為三層邏輯結(jié)構(gòu)的簡(jiǎn)易關(guān)系圖

 

 

以上是簡(jiǎn)易的系統(tǒng)邏輯結(jié)構(gòu)，***Action繼承于xwork的SupportAction，通過(guò)Spring來(lái)進(jìn)行管理，在整個(gè)Spring的容器中，Spring負(fù)責(zé)管理整個(gè)系統(tǒng)的所有Bean，并負(fù)責(zé)初始化Bean之間的依賴關(guān)系。***Action中注入了服務(wù)層對(duì)象***ServiceImpl,而ServiceImpl又注入了***DaoImpl對(duì)象。下面會(huì)逐步細(xì)化上面的關(guān)系圖。

先看下面的web.xml配置

web.xml

    <display-name>Struts Blank</display-name>

    <context-param>

        <param-name>webAppRootKey</param-name>

        <param-value>wxy.root</param-value>

    </context-param>

    <!-- spring xml文件配置目錄在class目錄下的spring目錄中WEB-INF/classes/spring -->

    <context-param>

        <param-name>contextConfigLocation</param-name>

        <param-value>classpath*:spring/*.xml</param-value>

    </context-param>

    <!-- 配置log4j的日志信息WEB-INF/classes/config/log4j.properties -->

    <context-param>

        <param-name>log4jConfigLocation</param-name>

        <param-value>classpath*:config/log4j.properties</param-value>

    </context-param>

    <!-- 配置Character Encoding Filter -->

    <filter>

        <filter-name>encodingFilter</filter-name>

        <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>

        <init-param>

            <param-name>encoding</param-name>

            <param-value>UTF-8</param-value>

        </init-param>

    </filter>

    <!-- 配置Struts2 -->

    <filter>

        <filter-name>struts2</filter-name>

        <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>

    </filter>

    <filter-mapping>

        <filter-name>encodingFilter</filter-name>

        <url-pattern>/*</url-pattern>

    </filter-mapping>

    <filter-mapping>

        <filter-name>struts2</filter-name>

        <url-pattern>/*</url-pattern>

    </filter-mapping>

   

    <welcome-file-list>

        <welcome-file>index.html</welcome-file>

    </welcome-file-list>

    <!-- 載入Spring ApplicationContext -->

    <listener>

        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

    </listener>

    <!-- Spring 刷新Introspector防止內(nèi)存泄漏 -->

    <listener>

        <listener-class>org.springframework.web.util.IntrospectorCleanupListener</listener-class>

    </listener>
未完待續(xù).

 

        一個(gè)軟件的開發(fā)是一個(gè)極其復(fù)雜的過(guò)程，其中設(shè)計(jì)分析，設(shè)計(jì)、編碼、測(cè)試、維護(hù)等，而系統(tǒng)分析卻往往是一個(gè)軟件成敗的關(guān)鍵。
        如何進(jìn)行系統(tǒng)分析，以及如何傳遞分析的的結(jié)果文檔等，又是系統(tǒng)分析師的首要任務(wù)。系統(tǒng)分析對(duì)于任何人來(lái)說(shuō)都不是容易 ，它沒有規(guī)則的限定，它需要系統(tǒng)分析師的應(yīng)變，雖然有相應(yīng)的指導(dǎo)，但指導(dǎo)往往是教課書般，沒有一個(gè)項(xiàng)目一塵不變地去原用教課書上的東西，更多的是經(jīng)驗(yàn)。
        系統(tǒng)分析的成品即軟件需求分析說(shuō)明書，此書到底需要包括什么內(nèi)容，到底是什么。這個(gè)問(wèn)題很難回答，也許有很多人不加思索地可以答出，但我認(rèn)為這個(gè)問(wèn)題很難。這個(gè)由不同公司不同項(xiàng)目的具體情況決定的。從我的角度來(lái)看我覺得這個(gè)文檔中的內(nèi)容要走夠設(shè)計(jì)師們看懂并可以作出設(shè)計(jì)。既然是為設(shè)計(jì)作打算，那么設(shè)計(jì)需要什么內(nèi)容呢，這又涉及到設(shè)計(jì)方面的東西。
        需求來(lái)源于用戶的一些“需要”，這些“需要”被分析，確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說(shuō)明了產(chǎn)品必須或應(yīng)當(dāng)做什么。如果只有一些零碎的對(duì)話、資料或郵件，就認(rèn)為掌握了需求，那就是自欺欺人。需求是一個(gè)產(chǎn)品的源頭，它的好壞對(duì)產(chǎn)品的影響最大，就像一條河流，如果源頭被污染了，那么整條河流就被污染了。“用戶”是一種泛稱，可分為“客戶”，最終用戶或間接用戶。需求分為兩類，一類屬于需求開發(fā)，另一類屬于需求管理。需求開發(fā)分為需求調(diào)查、需求分析和需求定義。需求管理分為需求確認(rèn)、需求跟蹤和需求變更控制。需求開發(fā)的目的是通過(guò)調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。需求調(diào)查的目的是通過(guò)各種途徑獲取用戶的需求信息，產(chǎn)生《用戶需求說(shuō)明書》。需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等，常見的需求分析方法有“問(wèn)答分析法”和“建模分析法”等。需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果進(jìn)一步定義準(zhǔn)確無(wú)誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說(shuō)明書》，系統(tǒng)設(shè)計(jì)人員依據(jù)《產(chǎn)品需求規(guī)格說(shuō)明書》開展系統(tǒng)設(shè)計(jì)工作。需求管理的目的是在客戶與開發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。需求確認(rèn)是指在開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾，使需求文檔具有商業(yè)合同效果。需求跟蹤是指通過(guò)比較需求文檔和后續(xù)工作之間的對(duì)應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。需求變更控制是指依據(jù)“變更申請(qǐng)—審批—更改—重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。
         如何進(jìn)行需求分析是需求調(diào)研中最重要的一步。需求分析是指在需求開發(fā)過(guò)程中，對(duì)所獲取的需求信息進(jìn)行分析，及時(shí)排除錯(cuò)誤和彌補(bǔ)不足，確保需求文檔正確的反映用戶的真實(shí)意圖。分析方法大體有兩類：“問(wèn)答分析法”和“建模分析法”。問(wèn)答分析法：刨根究底地問(wèn)，如果問(wèn)題都被解答了，那么需求也就分析清楚了。建模分析法是指用圖形符號(hào)來(lái)表示、刻畫需求。
         在系統(tǒng)分析中，用例的重要性不用多說(shuō)。真正理解了用例，懂得利用用例來(lái)驅(qū)動(dòng)項(xiàng)目的開發(fā)，才能真正把握住需求的精髓。每個(gè)用例是一組場(chǎng)景的集合，而每個(gè)場(chǎng)景又是一個(gè)步驟序列。用例圖通常是供客戶和開發(fā)組參考的設(shè)計(jì)文檔的一部分。用例之間可以以兩種方式相互關(guān)聯(lián)，一種方式是包含，即在一個(gè)用例中重用另一個(gè)用例中的步驟。另一種方式叫擴(kuò)展，允許通過(guò)對(duì)已有用例增加步驟創(chuàng)建一個(gè)新的用例。用例之間的另外兩種關(guān)系是泛化和分組。泛化是指一個(gè)用例繼承了另一個(gè)用例。分組是一組用例的簡(jiǎn)單組織方式。 
       用例可以解釋為某個(gè)參與者要做的一件事。也可以解釋為一系列完成一個(gè)特定目標(biāo)的“功能”的組合。這一件事可以解釋為：1.這件事是相對(duì)獨(dú)立的。它不需要與其他用例交互而獨(dú)自完成參與者的目的。2.這件事的執(zhí)行結(jié)果對(duì)于參與者來(lái)說(shuō)是可觀測(cè)的和有意義的。3.這件事必須由一個(gè)參與者發(fā)起，不存在沒有參與者的用例。4這件事是以短賓短語(yǔ)出現(xiàn)。即這件事必須有一個(gè)動(dòng)作和動(dòng)作的受體。用例的背后是一種需求方法論。用例的核心是以參與者為核心，從參與者的角度描述他的日常工作，并分析這些日常工作是如何交互的。用例的首要目的不是要弄清楚某項(xiàng)業(yè)務(wù)是如何一步步完成的，而是要弄清楚有多少參與者？每個(gè)參與者都做什么？
         需求分析需要經(jīng)過(guò)業(yè)務(wù)建模、用例分析和系統(tǒng)建模三部分組成。1.業(yè)務(wù)建模的目標(biāo)是通過(guò)用例模型的建立來(lái)描述用戶需求，需求規(guī)格說(shuō)明書通常在這個(gè)階段產(chǎn)生。2.用例分析是分析員用OO的方法來(lái)分析業(yè)務(wù)用例的過(guò)程，這個(gè)階段稱為概念模型階段，這個(gè)階段通常使用無(wú)類型的用例。3.系統(tǒng)建模是將用戶的業(yè)務(wù)需求轉(zhuǎn)化為計(jì)算機(jī)實(shí)現(xiàn)的過(guò)程，這個(gè)階段通常使用無(wú)類型的用例和用例實(shí)現(xiàn)兩種類型。系統(tǒng)范圍、項(xiàng)目計(jì)劃和系統(tǒng)架構(gòu)通常在這個(gè)階段形成雛形。業(yè)務(wù)用例(business usecase),是用來(lái)描述用戶原始需求的，它的含義是站在用戶的角度，使用用戶的業(yè)務(wù)術(shù)語(yǔ)來(lái)描述用戶在其領(lǐng)域所做的事。業(yè)務(wù)用例命名，描述都必須采用純業(yè)務(wù)語(yǔ)言，不能出現(xiàn)計(jì)算機(jī)術(shù)語(yǔ)。業(yè)務(wù)模型是系統(tǒng)分析員和用戶討論需求，達(dá)到一致理解的基礎(chǔ)。只有完成下面的工作，才能算是業(yè)務(wù)模型已經(jīng)建立完成。1.發(fā)現(xiàn)和定義
       

1.使用@AspectJ標(biāo)簽
   在AspectJ5中增加了對(duì)Java5注解的完全支持，可以使用Java注解來(lái)取代專門的AOP語(yǔ)法，把普通的Java類(POJO)聲明為切面模塊。使用<aop:aspectj-autoproxy/>來(lái)開啟在POJO中通過(guò)注解來(lái)標(biāo)識(shí)切面模塊的識(shí)別功能。但目前Spring只支持其中部分標(biāo)簽，包括@Before,@AfterReturning,@AfterThrowing,@After,@Around等幾種。
2.基于Schema模式配置Spring AOP
通過(guò)Spring配置文件中通過(guò)AspectJ切入點(diǎn)語(yǔ)言表達(dá)式來(lái)定義切入點(diǎn)，并配置相關(guān)的增強(qiáng)Advice實(shí)現(xiàn)方法
<aop:config>
    <aop:pointcut id="somePointcut" ../>
    <aop:advisor id="someAdvisor" ../>
    <aop:aspect id="someAspect" ref="someBean">
        <aop:adviceType id="someAdvice" ../>
    </aop:aspect>
</aop:config>
3.基于Spring API的配置文件
包括如下內(nèi)容：
1.0個(gè)或多個(gè)切入點(diǎn)定義Bean,必須實(shí)現(xiàn)Pointcut接口
2.1個(gè)或多個(gè)通知實(shí)現(xiàn)Bean,必須實(shí)現(xiàn)Advice接口
3.0個(gè)或多個(gè)引介Bean,實(shí)現(xiàn)IntroductionInfo接口
4.1個(gè)或多個(gè)切面封裝Bean,必須實(shí)現(xiàn)Advisor接口
5.1個(gè)或多個(gè)真實(shí)業(yè)務(wù)Bean
6.1個(gè)或多個(gè)代理Bean

1.形式多樣的交流激發(fā)每個(gè)人的潛能
2.不可缺少的周末總結(jié)交流
3.改善工作環(huán)境，排除干擾
4.合理制定進(jìn)度計(jì)劃，不提倡加班