JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » JavaTwo 討論區 » 2003 JavaTwo  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
threaded modego to previous topicgo to next topic
話題被移動
該話題已被移動 - morchory , 2003-08-14 07:07
如果您尚不清楚該話題被移動的原因,請參考論壇規則以及本版公告或者聯系本版版主。
本主題所含的標籤
無標籤
作者 今天聽了葉先生的AspectJ [精華]
joeyli





發文: 105
積分: 5
於 2003-08-12 22:24 user profilesend a private message to usersend email to joeylisearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
覺得他講得很好.........
瞭解了新一代的程式語言, 將OOP經由不同面向觀點的分層區分後,提出的加強語言即為AOP(Aspect-Oriented Programming)。主要是將原本因為不同面向因素(例如:security, persistence....)而交雜的Code分開處理。
在本質上這個觀念並不新穎, 依據機能或觀點分層的概念在Software Architecture層次早就存在。只是目前打算更全面性的落實在Source Code view上。

哲學層面上更是如此,一件東西原本就因我們對其的觀察而存在無數面,但真正的本質卻只有一個,且是永遠也看不清楚的那一個..........
故,為這樣的狀況留下彈性是必要的!

AOP就實務面而言尚須接受考驗,但就意義層面上來看,這樣的技術是可行且值得持續關注的。

在葉先生整個說明中唯一不是很認同的,就是在架構層面上若有依據不同機能或面向的分層後(當然是已經可預知的面向),其實就會解決部分的問題,也就是說不太可能所有面向的Code在落實到實作系統時都直接寫在Domain Object中,所以事實上Domain Object中的Code應該不會那麼樣的雜。
但,單靠架構面的設計的確沒辦法將Source code切得完善(對每一行Code),當然,還有本質上未來會有未知面向觀點出現的問題,所以AOP還是有其價值!
Software Architecture的設計概念上也一直沒能處理這種未知面向的問題,OMG提出的MDA(Model Driven Architecture,第二天的周教授會講)有點點這樣的意味,因為整個Model會被分為PIM與PSM,但對於未知面向的出現好像也沒處理得很好...............

在小弟的想像中,初期而言應當就如葉先生所說的,先處理關於Domain Object中的Source Code分層,因為這部分的Code最為精華,也最需要釐清。至於已經可預知的面向,就由Architecture其他不同層的Code協助處理囉!


joeyli edited on 2003-08-12 22:42
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
joeyli





發文: 105
積分: 5
於 2003-08-13 18:56 user profilesend a private message to usersend email to joeylisearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
今天照原訂計畫聽了周教授講MDA,正如事前的預料,
看來會當選本次研討會中最好睡的一場..........Tongue

就Architecture層次而言,希望保留最核心的Domain Model架構的目標並沒有改變,
在MDA中所指的就是PIM,而對於未知面向Model的MetaModel就利用MOF這樣的Meta-MetaModel去進行更上層的規範。
PSM未來可能會因為無數種面向而出現不同的MetaModel,希望用一個很高的抽象層次,來解決這樣的問題。

至於是不是解的漂亮.............還是老話:尚待考驗!

事實上,小弟事前對MDA也有稍微的瞭解,本來的想像是在比較通用性的MOF Modeling工具與PSM mapping工具整套
完整出來後才會有實作系統現身(這也是OMG所預想的....搭配工具廠商的發展時程),MDA Modeling就像周教授說
的,大部分UML繪圖工具都已經可以支援MOF Modeling描述並吐出XMI,至於真正的相容性就.............

不過,最大的問題還是出在PIM與PSM之間的mapping rule這方面的工具缺乏,萬萬沒想到周教授來個暴力上,硬是將自己的
PSM mapping tool作出來,還做出自己的Workflow PIM與WfMC PSM間的mapping引擎,果然是學術研究單位,真是沒話說!

可以看得出來,MDA最想解決的是企業Model在已知IT平台間的轉換問題,並藉此保留Model對未知平台的轉換彈性。簡單的
說,原本Domain Model與IT平台(或AP平台)間存在的gap都在實作層以coding的方式彌補,只是現在將填補的層次拉高到
Model層。
至於其間的取捨,小弟拙見認為,若行MDA就像進行一項百年大計的規劃一樣,除了要Modeling PIM之外,還要自己進行與
PSM間的mapping,除非市場上工具與作業方法非常成熟,否則與重新coding比較並不會輕鬆到哪去。況且.....還要擔保MDA
這樣的觀念有推起來,百年後還存在,否則............

有偷喵到葉先生也來聽了,不知他有何看法呢?


作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
Yoshi

塵世中一個迷途小書僮

版主

發文: 874
積分: 22
於 2003-08-13 19:26 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
joeyli wrote:
覺得他講得很好.........
瞭解了新一代的程式語言, 將OOP經由不同面向觀點的分層區分後,提出的加強語言即為AOP(Aspect-Oriented Programming)。主要是將原本因為不同面向因素(例如:security, persistence....)而交雜的Code分開處理。
在本質上這個觀念並不新穎, 依據機能或觀點分層的概念在Software Architecture層次早就存在。只是目前打算更全面性的落實在Source Code view上。


我也覺得他講得很好, 我原本以為我會聽不懂
但是他由淺入深的介紹, 以及一些簡單易懂的例子都很好
是我這二天聽過得課覺得最好的一場, 侯老師的也不錯
還有Borland雖然是廠商的場次, 但是我覺得他也算是概要的介紹了XP
我覺得對我還算滿有幫助的

讓我比較失望的是蔡學鏞先生的場次...我覺得某些key point講得不夠清楚
反而花了不少時間著重在我覺得不重要的地方...(安裝portal應該帶過就好了吧...)

web service講得太趕了, 感覺有點混亂
不過我覺得內容還是滿不錯的, 拿一些他做的案子來比較
我覺得還滿容易懂的

以上純屬我個人的感想



YOSHI!
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
william





發文: 49
積分: 4
於 2003-08-13 19:53 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
joeyli wrote:
在葉先生整個說明中唯一不是很認同的,就是在架構層面上若有依據不同機能或面向的分層後(當然是已經可預知的面向),其實就會解決部分的問題,也就是說不太可能所有面向的Code在落實到實作系統時都直接寫在Domain Object中,所以事實上Domain Object中的Code應該不會那麼樣的雜。

但,單靠架構面的設計的確沒辦法將Source code切得完善(對每一行Code),當然,還有本質上未來會有未知面向觀點出現的問題,所以AOP還是有其價值!


其實我講的是比較極端的、比較偏本質上的情況。

以傳統 OO 技術而言, 如果事前 analysis/design 做得非常好,
高中低階 layers 也切得很妥當,
的確較能 localize 已知的面向、周邊的服務、系統內的糾葛,
的確也較能從容應付未來新冒出的未知面向。

以 AOP 而言, 縱然本質上比較能優雅地面對未知的面向,
但是, 如果先前 domain modeling 的 analysis 及 design 沒做好,
整個 domain model 像是一塊巨石, 那麼,
AOP 也很難找到適當的「穴道」下針。

AOP 畢竟仍是新生兒, 還有許多理論及實務議題需要發掘與辯證,
就像 80 到 90 年代初期 OO 百家爭鳴的盛況一樣,
現在 AOP 也有一大堆派別, 各派歧異之處仍然很多。

Communications of the ACM 在 2001/10 的專題,
以及 Generative Programming 一書,
可看出這領域眾聲喧嘩的熱鬧景象。

以上這些觀點, 在會後和觀眾交流時, 我有稍微提到。


Software Architecture的設計概念上也一直沒能處理這種未知面向的問題,OMG提出的MDA(Model Driven Architecture,第二天的周教授會講)有點點這樣的意味,因為整個Model會被分為PIM與PSM,但對於未知面向的出現好像也沒處理得很好...............


廣義的 model-driven 方法並未試圖解決未知面向的問題,
而狹義的 OMG MDA 並未試圖解決未知「功能面向」的問題,
只試圖解決未知「platform 面向」的問題,
至少以目前而言。


在小弟的想像中,初期而言應當就如葉先生所說的,先處理關於Domain Object中的Source Code分層,因為這部分的Code最為精華,也最需要釐清。至於已經可預知的面向,就由Architecture其他不同層的Code協助處理囉!


Yes, 這是目前最安全的 AOP 做法。

各家各派的 AOP, 對於 crosscutting concerns 的本質,
仍然有許多研究的空間;
對於 join point model 的認識及實作,
也有待更多現實系統的考驗與回饋。


william edited on 2003-08-13 20:41
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
william





發文: 49
積分: 4
於 2003-08-13 20:38 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
joeyli wrote:
有偷喵到葉先生也來聽了,不知他有何看法呢?


被點名了... 本來想說今天穿得比較普通一點, 應該不會被認出來... :Q


今天照原訂計畫聽了周教授講MDA,正如事前的預料,
看來會當選本次研討會中最好睡的一場..........Tongue


我覺得, 如果把比較中間的那一頁 M0∼M3 挪到前面講
(以 workflow 為例, 講述 meta-model、PIM/PSM/codegen 通盤架構),
半數以上的觀眾會比較容易進入狀況吧。


就Architecture層次而言,希望保留最核心的Domain Model架構的目標並沒有改變,
在MDA中所指的就是PIM,而對於未知面向Model的MetaModel就利用MOF這樣的Meta-MetaModel去進行更上層的規範。
PSM未來可能會因為無數種面向而出現不同的MetaModel,希望用一個很高的抽象層次,來解決這樣的問題。

至於是不是解的漂亮.............還是老話:尚待考驗!


model driven 的觀念, 是軟體界很早就有的夢想,
至少像 Petri net 這種東西就已經行之有年。
只不過現在 OMG 藉由過去 CORBA IDL 及
UML meta-model 制訂經驗, 看到了這方面的標準化潛力,
再加上 XML 做為 serialized form 的態勢明顯,
便加把勁兒, 訂出這種參考模型。

不同的 model driven 派別, 著眼於不同的議題。
有的著重於 model 的自動驗證性, 有的著重於 domain 的完備性。
至於 OMG MDA 嘛... 以我今天聽到的感覺
(我以前只看過 XMI 的資料, 沒研究 OMG PIM/PSM 架構),
似乎比較著眼於同一份 domain model 在異質架構的獨立性。

說得更極端一點, 我認為, OMG MDA 的真正牛肉 (及挑戰),
在於 models 之間的 clean separation 及 mapping,
至於 MOF、XMI 等等, 甚至 JMI 云云,
都只是無關真正痛癢的錦上添花之舉,
傳統技術也辦得到, 只是不那麼標準化罷了。

不過, 如果這講座只講真正牛肉, 而不講那些周邊事宜,
那又變成 100% 學術講座了... :<


事實上,小弟事前對MDA也有稍微的瞭解,本來的想像是在比較通用性的MOF Modeling工具與PSM mapping工具整套
完整出來後才會有實作系統現身(這也是OMG所預想的....搭配工具廠商的發展時程),MDA Modeling就像周教授說
的,大部分UML繪圖工具都已經可以支援MOF Modeling描述並吐出XMI,至於真正的相容性就.............

不過,最大的問題還是出在PIM與PSM之間的mapping rule這方面的工具缺乏,萬萬沒想到周教授來個暴力上,硬是將自己的
PSM mapping tool作出來,還做出自己的Workflow PIM與WfMC PSM間的mapping引擎,果然是學術研究單位,真是沒話說!


的確是滿暴力的。

可是如此一來, 這套 workflow 系統用不用 OMG MDA 來做, 似乎無關宏旨。

如果這套系統的 mapping rules 本質上無法再加以 generalize 至其他 domains,
那麼, 這套系統的 PIMs 也沒多少互通性及獨立性 (和特定的 mapping 綁死);
那跟自己硬做一套專屬的 workflow visual modeling 系統,
那跟自己用傳統方式自訂一套 domain language 或 little language,
再拿 yacc 來自己針對各種底層 platforms 寫一套特定的 codegen,
又有多少分別呢?


可以看得出來,MDA最想解決的是企業Model在已知IT平台間的轉換問題,並藉此保留Model對未知平台的轉換彈性。簡單的
說,原本Domain Model與IT平台(或AP平台)間存在的gap都在實作層以coding的方式彌補,只是現在將填補的層次拉高到
Model層。
至於其間的取捨,小弟拙見認為,若行MDA就像進行一項百年大計的規劃一樣,除了要Modeling PIM之外,還要自己進行與
PSM間的mapping,除非市場上工具與作業方法非常成熟,否則與重新coding比較並不會輕鬆到哪去。況且.....還要擔保MDA
這樣的觀念有推起來,百年後還存在,否則............

有偷喵到葉先生也來聽了,不知他有何看法呢?


您講得很對, 有講到核心。 Smile

當場我有一個問題, 只是不及詢問。
印象中, 投影片裡面在講 MDA 分層的架構圖上,
箭頭不只是從 PIM 指到 PSM, 還有一個是從 PSM 指回 PIM。
呃... 我滿懷疑這第二箭頭的可行性。


william edited on 2003-08-13 20:43
作者 Re:今天聽了葉先生的AspectJ [Re:william]
joeyli





發文: 105
積分: 5
於 2003-08-13 22:59 user profilesend a private message to usersend email to joeylisearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
william wrote:
被點名了... 本來想說今天穿得比較普通一點, 應該不會被認出來... :Q


Sorry!沒想到真把您挖出來了,實在不好意思!
小弟生性害羞,講座後又有眾多聽眾圍繞葉先生,出此下策,先說聲抱歉了!


廣義的 model-driven 方法並未試圖解決未知面向的問題,
而狹義的 OMG MDA 並未試圖解決未知「功能面向」的問題,
只試圖解決未知「platform 面向」的問題,
至少以目前而言。


這點您說得沒錯,是我想太多了Tongue


我覺得, 如果把比較中間的那一頁 M0∼M3 挪到前面講
(以 workflow 為例, 講述 meta-model、PIM/PSM/codegen 通盤架構),
半數以上的觀眾會比較容易進入狀況吧。

model driven 的觀念, 是軟體界很早就有的夢想,
至少像 Petri net 這種東西就已經行之有年。
只不過現在 OMG 藉由過去 CORBA IDL 及
UML meta-model 制訂經驗, 看到了這方面的標準化潛力,
再加上 XML 做為 serialized form 的態勢明顯,
便加把勁兒, 訂出這種參考模型。

不同的 model driven 派別, 著眼於不同的議題。
有的著重於 model 的自動驗證性, 有的著重於 domain 的完備性。
至於 OMG MDA 嘛... 以我今天聽到的感覺
(我以前只看過 XMI 的資料, 沒研究 OMG PIM/PSM 架構),
似乎比較著眼於同一份 domain model 在異質架構的獨立性。

說得更極端一點, 我認為, OMG MDA 的真正牛肉 (及挑戰),
在於 models 之間的 clean separation 及 mapping,
至於 MOF、XMI 等等, 甚至 JMI 云云,
都只是無關真正痛癢的錦上添花之舉,
傳統技術也辦得到, 只是不那麼標準化罷了。

不過, 如果這講座只講真正牛肉, 而不講那些周邊事宜,
那又變成 100% 學術講座了... :<

這恐怕就是技術研討會的原罪吧!
不過,覺得這次大會在議題上整體的安排已經相當不錯了!


的確是滿暴力的。

可是如此一來, 這套 workflow 系統用不用 OMG MDA 來做, 似乎無關宏旨。

如果這套系統的 mapping rules 本質上無法再加以 generalize 至其他 domains,
那麼, 這套系統的 PIMs 也沒多少互通性及獨立性 (和特定的 mapping 綁死);
那跟自己硬做一套專屬的 workflow visual modeling 系統,
那跟自己用傳統方式自訂一套 domain language 或 little language,
再拿 yacc 來自己針對各種底層 platforms 寫一套特定的 codegen,
又有多少分別呢?


.......小弟和您的想法一樣,不過,想來學術研究就是這樣吧!周教授他應該也想在完整tools尚未推出前實作一下,只不過這樣做還看不出來具體的優點。
實際上MDA一切也只能看tools 後續的發展.......


您講得很對, 有講到核心。 Smile

當場我有一個問題, 只是不及詢問。
印象中, 投影片裡面在講 MDA 分層的架構圖上,
箭頭不只是從 PIM 指到 PSM, 還有一個是從 PSM 指回 PIM。
呃... 我滿懷疑這第二箭頭的可行性。


由第19張投影片來看,感覺MDA的隱喻像擁有一貫化製程的工廠,PIM由Domain Expert與SA產出,
然後由Meta-Model & Rules developer定義的PSM Metamodels與PIM2PSM Mapping engine將
PIM轉為PSM,也就是想藉著Modeling到Coding整體的自動化來降低Architect影響力。
若由此來看,只要mapping engine寫好,PSM與PIM間的正向逆向轉換應當是可能的吧?(純臆測)

針對您提到的第5張投影片中,我覺得奇怪的倒是若MDA這樣的東西真的成立的話,照理說連Code
反轉為PSM都應當是可能的,但該圖中PSM與PIM間可逆,Code與PSM間不可逆,實在搞不懂.......

不過,就現實面而言小弟是完全認同您的說法,在Model間的轉換中絕對是會lose一些東西的。

對於MDA這類東西小弟個人向來持質疑的成分較大,追求完全的自動化向來是人類的夢想,但
越是偏向創意、設計面的東西(摻雜右腦思考的東西)越難做到完全的自動化。這在其他的領域
如機械、建築業中早已獲得證明。無奈...........


joeyli edited on 2003-08-13 23:03
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
william





發文: 49
積分: 4
於 2003-08-14 03:07 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
joeyli wrote:
這恐怕就是技術研討會的原罪吧!
不過,覺得這次大會在議題上整體的安排已經相當不錯了!


呃, 澄清/補充一下, 我認為周教授講的東西,
對於一般聽眾而言, 頗有拓展視野的效果。
畢竟連資訊科班人也未必全都有碰過
modeling、formal method 之類的玩意兒。
藉這講座刺激一下思考也不錯,
總不能成天都是 J2EE 或 J2ME 嘛, 呵。

對 workflow modeling 工具相關從業人員而言,
把既有系統包裝、套上 OMG MDA 標準及 XMI、JMI 等東東,
在商業行銷上更有加分作用。


作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
sho





發文: 14
積分: 1
於 2003-08-14 11:07 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
周老師 MDA 那場的系統是我學長的論文..
可以看看....
http://datas.ncl.edu.tw/cgi-bin/theabs/1/flyweb.cgi?p=4713&i=5271168&t=497&o=v1

如果有人有幸趣我可以問問學長能不能放上來


作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
jini

SoftLeader Taiwan

版主

發文: 1266
積分: 23
於 2003-08-15 01:14 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我只聽了 william's AspectJ..
所以我對這次 javatwo 的整體評價不錯
完全是因為 william 的演說不錯

不過有一個很讓人意猶未盡的地方
花了大多的時間強調 OOP 的不足來突顯 AOP 的輔助必要性
AOP 真正敘述到的時間僅有短短的十分鐘左右
真的會讓我期待下一次更精闢的演說


作者 Re:今天聽了葉先生的AspectJ [Re:jini]
william





發文: 49
積分: 4
於 2003-08-15 02:10 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
jini wrote:
我只聽了 william's AspectJ..
所以我對這次 javatwo 的整體評價不錯
完全是因為 william 的演說不錯

不過有一個很讓人意猶未盡的地方
花了大多的時間強調 OOP 的不足來突顯 AOP 的輔助必要性
AOP 真正敘述到的時間僅有短短的十分鐘左右
真的會讓我期待下一次更精闢的演說


謝謝您的稱讚! Smile

本來前半段的部分, 只打算講 40∼45 分鐘,
剩下 25∼30 分鐘講第二部份。
可惜臨場時, 話匣子突然收不回來,
所以在 AspectJ 程式例子及 demo 方面,
有點匆促, 自己也覺得有點遺憾。

或許找個時間寫些連載文章來彌補一下。


作者 Re:今天聽了葉先生的AspectJ [Re:jini]
annhy

來呦~



發文: 45
積分: 2
於 2003-08-16 14:39 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
jini wrote:
不過有一個很讓人意猶未盡的地方
花了大多的時間強調 OOP 的不足來突顯 AOP 的輔助必要性
AOP 真正敘述到的時間僅有短短的十分鐘左右
真的會讓我期待下一次更精闢的演說


嗯,我也有同感。

前面那一大段,對我來說,聽起來有點.. 呃... 太抽象..

所以為了不讓周圍的人發現我的程度很差,只好頻頻點頭裝懂。 Tongue
怎麼都無法理解那個什麼 多維度 的東西,虧我以前還是學數學的。 Black Eye

結果後面一看到程式,我就完全瞭解到底前面在說些什麼了。


作者 Re:今天聽了葉先生的AspectJ [Re:annhy]
william





發文: 49
積分: 4
於 2003-08-16 17:44 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
annhy wrote:
嗯,我也有同感。

前面那一大段,對我來說,聽起來有點.. 呃... 太抽象..

所以為了不讓周圍的人發現我的程度很差,只好頻頻點頭裝懂。 Tongue
怎麼都無法理解那個什麼 多維度 的東西,虧我以前還是學數學的。 Black Eye


本來我曾考慮過, 在前半部講三個 OO 問題時,
以「a. 問題描述, b. OO 困境, c. AOP 具體解法」的小循環為基準,
逐一把三個問題 iterative/incremental 講完,
可能觀眾會比較有具體的感受。

不過, 如果用這種方法編排演講,
粗估了一遍, 時間大概會拖更久... :q

更重要的是, 這樣可能會太早就把觀眾的想像力侷限住,
甚至侷限在 AspectJ 一派的解法,
忽略了更深一層的 AOP 理念。
畢竟 AspectJ 只是 AOP 的一派, 而且仍有改進成長的空間。


結果後面一看到程式,我就完全瞭解到底前面在說些什麼了。


其實後面那些程式, 說起來太小兒科了,
理想一點的做法, 應該要找多一點的現成實例,
展示一下前半部批判 OO 力有未逮的那些例子,
對比出 AOP 到底是否真的有比 OOP 好。

不過時間有限, 連 dining philosopher 的 applet 例子都無法細說。

若拿真正的現成實例來玩, 又會扯出目前 AOP 觀點所面臨的挑戰... :q


william edited on 2003-08-16 17:46
作者 Re:今天聽了葉先生的AspectJ [Re:william]
browser

戀香

版主

發文: 3570
積分: 1
於 2003-08-16 19:39 user profilesend a private message to usersend email to browsersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
william wrote:
本來我曾考慮過, 在前半部講三個 OO 問題時,
以「a. 問題描述, b. OO 困境, c. AOP 具體解法」的小循環為基準,
逐一把三個問題 iterative/incremental 講完,
可能觀眾會比較有具體的感受。

不過, 如果用這種方法編排演講,
粗估了一遍, 時間大概會拖更久... :q

更重要的是, 這樣可能會太早就把觀眾的想像力侷限住,
甚至侷限在 AspectJ 一派的解法,
忽略了更深一層的 AOP 理念。
畢竟 AspectJ 只是 AOP 的一派, 而且仍有改進成長的空間。

其實後面那些程式, 說起來太小兒科了,
理想一點的做法, 應該要找多一點的現成實例,
展示一下前半部批判 OO 力有未逮的那些例子,
對比出 AOP 到底是否真的有比 OOP 好。

不過時間有限, 連 dining philosopher 的 applet 例子都無法細說。

若拿真正的現成實例來玩, 又會扯出目前 AOP 觀點所面臨的挑戰... :q


我也覺得前面批判 OOP 的部分真的太長了 .... (也因如此,我也才知道 OOP 的缺憾)
會來聽這場 AOP 的人...
應該都想知道 AOP 如何解決目前 OOP 所遇到的瓶頸 ....
結果 .. 沒想到 .. AOP 一下子就講完 ...
讓我覺得意猶無盡 ....

不過真的很希望 william 兄 ... 能夠在此多加一點補充 ...
讓大家能夠多認識 AOP ....

=============================================
AOP是今年 JavaTwo 最精彩的場次 ...
唯一的缺憾 ... 時間太短 ....... 真希望多聽一些 ....



作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
rBen



發文: 0
積分: 0
於 2003-08-20 01:12 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list

joeyli wrote:
在小弟的想像中,初期而言應當就如葉先生所說的,先處理關於Domain Object中的Source Code分層,因為這部分的Code最為精華,也最需要釐清。至於已經可預知的面向,就由Architecture其他不同層的Code協助處理囉!

Willian wrote:
Yes, 這是目前最安全的 AOP 做法。


很感謝能聽到大家對AOP的觀念和看法,獲益良多! 上面提到的Domain Object Source Code 分層概念可否再多多說明一下,分層的意義上是根據原本的architecture layer嗎? 還是透過state diagram or sequence diagram 的再分析進行橫向切割的模組化呢? 或是其他??


作者 Re:今天聽了葉先生的AspectJ [Re:rBen]
joeyli





發文: 105
積分: 5
於 2003-08-20 21:24 user profilesend a private message to usersend email to joeylisearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
rBen wrote:
很感謝能聽到大家對AOP的觀念和看法,獲益良多! 上面提到的Domain Object Source Code 分層概念可否再多多說明一下,分層的意義上是根據原本的architecture layer嗎? 還是透過state diagram or sequence diagram 的再分析進行橫向切割的模組化呢? 或是其他??


首先,無論是Architecture分層或是AOP,中心思想都在於期望將Domain Object內的運算邏輯單純化,保護Domain Object真正處理商業邏輯的Code不會被淹沒在其他為了處理已知或未知面向(也就是葉先生說的維度)的code中,而模糊了真正的焦點。

至於,怎麼樣的Code才算是真正的商業邏輯?可能每個人的定義角度不同....不過,盡量將僅為了解決IT平台問題的Code與Domain Object分離開來則是可以肯定的一件事。
例如:security、persistence, log, 甚至是UI.......等等。舉個大家都知道的例子,長期以來在Java中的JDBC、Entity Bean到現在的Hibernate、JDO,就是希望將persistence面漂亮的隔離開來。(看來是有越來越漂亮了.....)

由這裡可以發現,基本上原本的Architecutre Layer的分層大多是針對已知的問題面向進行處理,尤其是針對既存的IT面問題,若能在架構設計的階段妥善分層,且於OOA/D階段對Domain Object間的responsibility多加用心的處理,事實上Domain Object中的Code會乾淨許多,但,不可能完全乾淨。

這時候就可以看到AOP的優勢,因為它可以處理未知面向的問題,將屬於商業邏輯以外的Code都一層層的另疊上去,而且在Code的層面而言也能完全釐清它們的關係。
舉個例子,小弟目前沒有使用AOP,所以在Domain Object中都只寫重要的商業邏輯Code,且加強它們的Unit test,就是為了不想將log這樣的東西寫在Domin Object中,不但礙眼,且模糊了Code真正的焦點。
若利用AOP,就可以另外寫log面向的Code,在編譯或Run time時期再疊到原本的Domain Object上,這樣一來就能夠保護原本的作商業邏輯的Code不會被污染,且又能得到 log的機能了。


joeyli edited on 2003-08-20 21:44
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
rBen



發文: 0
積分: 0
於 2003-08-21 19:19 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
tks joeyli ~ Smile
透過joeyli的說明,我的理解,似乎理想上採取AOP並不會也不應影響原本Domain logic的程式架構,但卻可以經由加載AOP方法反應出不同面向的concern,同時也大大降低原本必須到各個與concern相關class的coding程式碼數量。(如log)

但我關心的是在當我們欲透過AOP programming時,必定會發生對舊的原本Domain logic進行模組化切割與重組(cutting,weaving),正如log的觀念若原本"散落於各處"的相關程式碼(顯然對於log concern不符合低耦合高內聚軟體工程要求)crosscuting 拉出來進行implement最後再套用原本的class.

所以程式碼的內涵透過AOP將有如下的改變:
Domain logic (含log,security,transation...concern) --模組化(SOC)--> Domain logic (Base) + AOP codes
此時Domain logic(Base)將不再交雜的含有任何Concern的程式碼,而將屬於Concern的專責交由AOP codes負責,AOP codes會幫助將各個concern的logic塞入回Domain logic(Base)

所以,若原本透過OOAD架構而成Domain framework 要向AOSD+OOAD轉移時是否需要經過某種標準程序,將Domain進一步的refactoring.
是否對於Domain中 的Business logic class 需要劃分為pure logic and concernable logic二個區塊?


rBen edited on 2003-08-21 19:47
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
Shen





發文: 167
積分: 3
於 2003-08-21 21:22 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
請問一下什麼是Domain Object、Domain logic呢?
謝謝!!


作者 Re:今天聽了葉先生的AspectJ [Re:rBen]
popcorny

Jakarta 2%

版主

發文: 752
積分: 20
於 2003-08-21 21:55 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
你好..
我提出一點我的淺見
有關OOP程式refactor到AOP的程式
我想現在討論這個還有點言之過早..
畢竟AOP只是一個概念...要怎麼實作才比較漂亮..
到現在好像也沒有一個大家普遍認同的方法

像AspectJ的做法是一種做法...
透過定義一些aj檔來描述不同aspect的code..
但是這就有你提到要花很大的功夫要把既有oop的架構轉成aop的架構...
代價跟風險都非常不符合效益

也許有另外的方法可以實作AOP
如:jdk1.5的metadata.. 或許也是一個方向...
若可以用metadata的方法來描述某部分為某個aspect的code...
之後IDE整合時...甚至可以做到只呈現某些aspect的code....
有點像是photoshop layer的概念...
這個好處是IDE容易整合...
原有的code好改寫
程式設計者也好寫程式...
(在寫domain logic時把所有aspect code關掉..
在寫aspect logic時只顯示自己的aspect跟domain logic)
這也許也是一個辦法...

當然還有更多的方法可以實作AOP...
所以當大家已經有一個共識又怎麼實現AOP時
再來討論怎麼把OOP的code轉成AOP的code會比較實際
現在在怎麼想也是空想..
當然...如果要真的深入研究這個領域就另當別論啦


browser edited on 2003-08-21 22:11
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
joeyli





發文: 105
積分: 5
於 2003-08-21 23:57 user profilesend a private message to usersend email to joeylisearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
小弟個人同意 popcorny的說法........

AOP在本質上而言是相當可行的,所以值得我們持續對它關注、研究。

至於rBen兄想瞭解將AOP導入原本的OO架構的 Framework,小弟才疏學淺也不瞭解應如何進行,已經經歷一段時間精鍊的Framework是不是還需要AOP的改良?這恐怕要等到AOP的作法更明朗化的時候才能進行評估吧!


作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
popcorny

Jakarta 2%

版主

發文: 752
積分: 20
於 2003-08-22 00:15 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
jboss號稱在未來新的版本(4.0)是AOP的
感覺上是用傳統的OOP方式整合進他們的framework中...
可以看看jboss上的介紹
http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop


popcorny edited on 2003-08-22 00:18
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
rBen



發文: 0
積分: 0
於 2003-08-22 00:57 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
小弟脫口而出"framework"這個字好像造成了困擾Stupid 也太沈重 Tounge
其實我想知道的是有了AOP哪些事情改變了,並且要如何改變∼

我也介紹一個網站 -- http://jac.aopsys.com
和不錯的aosd2003簡報 -- http://aosd.net/archive/index.html


作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
zodiac





發文: 8
積分: 0
於 2003-08-22 11:41 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
當初看到jboss 4 說他們用到AOP,我覺得很訝異,到處問人有沒有人懂或有實際經驗,結果是NO.
好像當初jboss 3說把底層用JMX做所謂的kernal 時一樣,問別人有沒有人熟悉jmx,結果也是NO

當初OO的理論出來到實際業界大量使用的時候,也經過好多年(因為教育和市場觀望的原因)。不知道AOP是不是也會需要好多年學術的探討,才會在業界風行。

請大家討論一下。


作者 Re:今天聽了葉先生的AspectJ [Re:rBen]
william





發文: 49
積分: 4
於 2003-08-22 15:27 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
rBen wrote:
小弟脫口而出"framework"這個字好像造成了困擾Stupid 也太沈重 Tounge
其實我想知道的是有了AOP哪些事情改變了,並且要如何改變∼

Communications of the ACM 在 2001/10 那一期有 AOP 專題,
裡面談了許多 AOP 派別。

如果懶得看那麼多文章, 可以只挑這兩篇「各言爾志」的文章:

1. Discussing aspects of AOP
  AOP 各派掌門人大鳴大放:現況、挑戰、未來
  http://doi.acm.org/10.1145/383845.383854

2. Analyzing the role of aspects in software design
  各派作法總覽及評比
  http://doi.acm.org/10.1145/383845.383859

尤其是第二篇文章的示意圖, 應該很容易把各派 AOP 做法歸定位。

如果還有空, 可再看兩篇淺易的文章:

3. Aspect-oriented programming: Introduction
  入門概論
  http://doi.acm.org/10.1145/383845.383853

4. Does Aspect-Oriented Programming Work?
  案例研討
  http://doi.acm.org/10.1145/383845.383862

popcorny wrote:
jboss號稱在未來新的版本(4.0)是AOP的
感覺上是用傳統的OOP方式整合進他們的framework中...

rBen wrote:
我也介紹一個網站 -- http://jac.aopsys.com
和不錯的aosd2003簡報 -- http://aosd.net/archive/index.html

目前看起來, 仍然是「在語言層次提供 AOP 能力」比較漂亮。
只要再多吸收一點其他各派的優點,
像 meta-object protocol、reflection 等,
威力也會有更進一步的提升。

原本我有考慮在 JavaTwo 提一下 JBoss, 但看了一下,
覺得實在沒有 AspectJ 來得漂亮,
就沒浪費時間提它了。

如果以後 JBoss 有把它弄得漂亮一點,
或許明年我會考慮。 Smile


william edited on 2003-08-22 15:31
作者 Re:今天聽了葉先生的AspectJ [Re:joeyli]
saijone

Web Services

版主

發文: 470
積分: 24
於 2003-08-24 11:17 user profilesend a private message to usersearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list

原本我有考慮在 JavaTwo 提一下 JBoss, 但看了一下,
覺得實在沒有 AspectJ 來得漂亮,

BEA 的 WebLogic Aspect Framework 是建構在 AspectJ 上. 只知道它提供了一些已定義
好的 pointcut (如 Servlet 的 service(), JMS 的 onMessage()) 來方便 user 建立 aspect
http://dev2dev.bea.com/resourcelibrary/utilitiestools/monitoring.jsp

BEA 和 JBoss 兩派人馬也在為了誰先誰後的問題在 TSS 上大戰 What are you talking about? :
http://www.theserverside.com/home/printthread.jsp?thread_id=20514


所以程式碼的內涵透過AOP將有如下的改變:
Domain logic (含log,security,transation...concern) --模組化(SOC)--> Domain logic (Base) + AOP codes
此時Domain logic(Base)將不再交雜的含有任何Concern的程式碼,而將屬於Concern的專責交由AOP codes負責,AOP codes會幫助將各個concern的logic塞入回Domain logic(Base)

個人以為 AOP 和 OOP 可以看成是不同層次的 solution. AOP 將整個系統的需求分成不同
的 concern, 其中也包含最主要的 business logic. 至於這些分好的, 不論是 crosscuting
concern 還是最主要的 business logic 你可以用 OO(或非OO)的做法來 implement, AOP
目的在於簡化 business logic 乃至每個 concern 的建構, 但可能不影響其架構. 最後由
aspect weaving 來完成原先內部交錯複雜的系統.

如果是要直接由J2SE的層次來建立一個系統, AOP 可以是一個很值得嘗試的方向, 相信會
是個很有趣的 Project.

但如果您想用或已經用了J2EE呢? 其實 J2EE Architecture 已經蘊含了 AOP 的精神, 像
security, transaction 或更高層次角度的 reliability, scalability 的需求, 這些 AOP 中的
crosscuting concern, 都應該由 J2EE Application Server 來提供, 以"方便"或支援 business
logic 的建構. 至於最後的 aspect weaving 或說 在 business logic 中使用這些 J2EE提供的
service, 則可以由 deployment descriptor 或甚至未來的 metadata (attribute) 來完成. 好
像有人叫這做Declarative programming 或另一種 AOP(Attribute-Oriented Programming).
像 BEA 或 JBoss 這樣願意朝 AOP嘗試的, 或者已經開始思考怎樣讓建構 J2EE App 成為
aspect oriented style, 將現有的各種 J2EE container service 做成 reusable crosscuting
concern implementation 嗎?

無論使用哪種方式或技術, 都不應該忘記或模糊了問題的本質 - 那就是要快速的完成一
個可靠可用便於維護的系統 - 這是 user 唯一關心的, 至於 developer 要用 AOP 還是要
OOP, J2SE 還是要 J2EE, Java 還是要 .NET, 一個可能最實際的作用是在 developer 的
resume/experience 上或可多一項 technical skill Smile


saijone edited on 2003-08-24 11:26

You don't need a reason to help people
» JWorld@TW »  JavaTwo 討論區 » 2003 JavaTwo

threaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8