May, 2005 > 所有文章列表
PB/OOAD: Pattern-Based Object Oriented Analysis and Design.
CBD: Component-Based Design.
SOA: Service Oriented Architecture.
這三個字真是 料多 實在 妙用無窮 啊~
任何一個好的、成熟的、複雜的專案，都應該遵照這三個原則，從一開始的規畫設計就整合Pattern與OO，並使用UML做為溝通的工具(我常用的幾種圖是 use case, class diagram, sequence diagram, ER，其它就隨緣了)，等A/D出來後，在實作階段就應該盡量採取Component-Based Design(在flash裏面，component可以是指單純的UI components，但也可以是多個UI components的集合單元)；而後端的部份則應該儘量採用SOA(不論是像.net的code behind, coldfusion的cfc或其它各種web service應用，總之後端服務應該有一定的封閉性，透過facade或adapter原理來操作)。
所以簡單來講，這三個字是有先後性的：
分析 - 前端實作 - 後端實作
PB/OOAD - CBD - SOA
雖然這三個字每個都不簡單，個個也都是大學問，但越早採用受益越多，對flash-based 的 RIA製作來說，比較大的難題可能是工程師得先從其它領域(.NET/JAVA)學會這些概念，然後再自行轉換到actionscript 2來，雖然過程中會造成進度遲緩，但就像大浪要來前必然會先退潮，退的越多後續沖上來的力道越強，一旦過了這個轉折之後就輕鬆了。
經過近兩個月的努力，最近我們終於完成一套貼近人性、彈性高又易用的framework(或稱做RIA best practice也行)，可以用最接近傳統win32 programming的方式達到快速開發(RAD)應用程式的效果，在未來幾個星期中我會將部份範例程式整理成教學文章放上來，請大家多指教。
ps. 經常被問到：為何我要這麼在意 方法論/framework/best practice/軟體工程 之類的東西，理由其實很簡單：
1、要認真開發商用軟體(不論是用flash/.net/java)，這都是必經的路，就跟做音樂一定要買mac是一樣的道理，雖然用其它方法也能達到類似效果，但路遙知馬力差別總有顯現出來的一天(而且往往會快的讓人嚇一跳)，所以與其繞路不如直指核心一次搞定最重要的部份。
2、受夠了flash向來惡名昭彰的惡搞開發流程，十個設計師寫出來的程式就會有二十種不同的手法跟三十種不同的錯誤加上四十個修不掉的bug，這一切會發生絕對都是有原因的，其中共通的一點就是在於先天缺乏正統的CS訓練，後天又沒有generally agreed-upon methodology可依循，再加上flash也是這一兩年才開始進入Application的開發領域，所以一切都太年輕、太混亂(不論是人、技術、市場皆是如此)。
| by admin
剛才程式寫到一半接到通電話，一聽就是濃濃的大陸腔，結果居然是對岸的軟體公司打來詢問是否有需要製作網站或外包技術製作，並且很積極的說明現在對岸的人力素質也很成熟，成本又低等等…
沒想到現在競爭這麼激烈，大陸公司案子都搶到台灣來囉~只是感覺總是很怪異，曾幾何時兩邊的界線變的這麼淡吶？越洋電話變的跟市內電話一樣普通 (難不成爺爺真的回來了？)
| by admin
上星期沒事玩了一下breeze 5，心得速記如下。
1、breeze 5有了全新的UI介面與部份更新的操作方式(例如layout記錄與可延展的pods)
2、breeze 有自已整套的components library，並且是從flash 2004裏面UIObject/UIComponent延伸修改而來，再加上約五六樣特製的小元件(例如 media display bar)
3、breeze也採用了central的 pods概念，也就是說app的layout佈局可由數個獨立的block組成(每個block就是一個所謂的pod)，例如 userlist 是一個pod, chat window是一個pod, desktop sharing是一個pod，video/audio window也是一個pod；而這些pod的內容實際上就是由眾多的 UI components所組成(也就是你也有的那些listbox, combox, datagrid, textarea….etc)。
所以我可以合理推測breeze team的開發流層可能是(或至少有下列)幾個階段：
-製作UI Components：這包含將flash 2004裏的元件 re-skinning貼上一層breeze專屬的視覺風格 與 撰寫額外需要的元件(例如back/fwd button)
-製作 PODS：整個breeze的畫面基本上就是由十來個不同的block(pods)所交又搭配組合而成，例如 meeting時可能出現的pod有：AV, chat, userlist, presentation, question, poll，而presentation時的pod可能又是另一組。因此只要分析出所有要用到的pods並製作完成，日後要重覆使用就很方便了。
-整合製作：將製作好的pods依不同layout設定整合到breeze app裏面，順便處理程式的其它流程，例如啟始流程與底層的 event handling等。
4、breeze一啟動後就會下載兩個 common library，分別是 BreezeUIComponents.swf(145kb) 與 CorePodsCollection.swf(116kb)，只要從cache裏挖出來再用*適當*的工具打開看一下就會瞭解breeze的運作原理。
5、有了上面兩個library後下一步當然是想玩玩看能不能*借*來用在自已的程式裏，但可惜即使知道每個元件的export id(linkage名稱)、路徑也設定正確，但仍然無法成功顯示，或許是我的操作方法不對。
不過由於這些components與pod本身的功能並無特別之處(意思是：自已寫一組也不會花太多時間因此不用浪費時間借別人的用，更何況可能會有版權問題)，且效能不是很好(尤其是window這個元件更是糟糕，一拖拉整個cpu resource就吃掉100%並且lag很嚴重，個人推測是被drawing API給搞死的，這是mm牌元件的通病)，所以借不成也就算了。
6、觀察breeze的分工模式與coding style非常有趣，從CorePods與meeting[1].swf兩支程式裏可以很詳細的看到macromedia工程師們的寫作風格與技術成熟度，例如他們也不約而同的捨棄了createClassObject而改用 attachMovie()，以及大量的hack手法，看者這些code幾乎可以感受到當時他們腦中的思路流程與採取的design decision，真是活靈活現吶~簡單來說breeze是一個滿成功的 application。
附帶一提，breeze拆開來看骨子裏就是一個 flash communication server + JRun application server + 一堆Actionscrpit Class(這堆classes 的集合體就叫做 Breeze)，或是換一個view來看，breeze = flashcom + JRun + (BreezeUIComponents + CorePodsCollection) + 很多的行銷跟銀彈(笑)。
當然每次講到這點都忍不住要再提一次：macromedia做為一家提供工具的公司，它的任務應該是盡責的將工具(flash, dreamweaver, Flashcom, Jrun, Coldfusion…)弄好，但應用程式級的開發(Breeze就是一個應用程式產品)則留給ISV或Consulting公司，所以市場的合理發展本來應該是像SAP這樣的公司用flash + flashcom + WebSphere/Tomcat/Jrun 開發出一套Breeze 產品，然後對外行銷，而不是由mm原廠利用對技術的獨佔優勢來開發利基產品搶佔市場(好吧，我知道對本站大部份的讀者來說你可能只是快樂的愛用者或工程師，但多知道世界的另一種面向並無害處對嗎？)
7、breeze 5仍然要靠 breeze-addin 這支執行檔才能提供screen sharing，這支程式基本上就是 flash player dll + screen capture driver + breeze swf，所以只要花點功夫替換掉breeze swf這段就可以借用 breeze-addin(以及，當然，最重要的screen capture功能)來玩自已的 screen sharing 應用，咳，這部份就暫且按下不表了。
目前我比較好奇的是，swf是跨平台的(win/mac/linux)，因此breeze 的主程式畫面一定可以正常顯示，但breeze-addin是一支win32 app透過下載到client端執行，那在mac與linux上難道也各有一支相對應的程式嗎？if(Previous_Statement == true){ this’s gonna be *VERY* interesting dude ! }
這部份我會找時間用mac與ubuntu連上去試試(當然最有可能的結果就是mm可以直接在system requirement裏寫只支援win32平台)
8、breeze 在很多層面都讓人覺得非常有趣，不單是它採用的component/pod結構與應用flashcom的方式，它的business model更是讓人大獲啟發，或許mm不應該跳進來搶ISV的市場(這是市場策略與道德的問題)，但老實說，mm做的真的很好，就像他們在其它利基市場的表現一樣(例如 Flex, 雖然現在它還貴的嚇人，但本質上是個不錯的產品，只要沒被adobe搞掛然後mm快點降價或採取其它銷售策略就大有可為)。
簡單一個結論就是：一般人覺得flashcom貴(二萬到二十萬不等視license而定)是因為只看到單一的server產品，但mm就懂得把餅搞大推出一個八十萬到一百萬的應用產品(也就是breeze提供的 meeting/presentation/training)，這下你不會覺得的貴了吧？這裏面的道理真是非常有啟發性，非常有趣。
| by admin
熱血青年的範例(英文)
cesar(怎麼聽都像狗食的名字啊…..)的blog寫了一系列以actionscript 2 為主的pattern 範例，其中 abstract factory與prototype pattern最為實用。
由於進行中的案子複雜度越來越高，最近非常頻繁的在處理as2 與 pattern的實作問題，在過程中開始漸漸發現actionscript compiler的一些缺點：
1、as compiler只會進行 compile time check(型別檢查等)，因此如果在runtime出現意外，往往不會被抓到，這是actionscript 1/2 不夠嚴謹的一面。
2、as2 不支援 abstract class與method overloading使得許多現代語言的優點(例如java, C#)無法port到as2，雖然變通的方法總是有，例如用 interface取代abstract class, 用switch case取代 overloading，或甚至用3rd party 像 as2lib這樣的library來硬加上這些功能，但這麼基本的東西仍然應該是成熟的現代語言該具備的。
3、as2的不嚴謹與獨特的class structure使得對compiler行為夠瞭解的工程師可以有許多後門，例如actionscript class一定要與某個mc結合才能出現在畫面上，而MC是當然的Object成員，因此在class 裏凡是不確定型別的物件，通常都可以用Object 騙過去。但這種泛Object的鬆散屬性往往也會帶來許多缺點，例如原本該被封裝在物件內的private property與 method在某些情況下會被reveal出來(例如跑個 for..in loop)，或是某個物件丟給dataset處理後再拿出來時型別已經變成統一的Object然後要自已再cast回去。
最後的結果就是：工程師(通常也就是我)得兼任compiler的角色，時時注意型別檢查與繼承鍊的維護，而習慣不好的工程師可能就樂得走後門隨意使用型別或class chain來快速達到目地(但造成後續維護困難甚至難以追蹤的bug)，本來這些事都應該在compiler這層負責把關並提醒的啊… orz
ps. 這些問題我已經當面問過 gary grossman(flash player / actionscript開發負責人) 許多次，每人都看者一個大鼻子露出自信的微笑點頭說 I know it, we are currently working on it…..
| by admin
最近教課剛好講到pattern的部份，所以把手邊幾本新進書翻了一下，其中這本是個人覺得最適合flash 工程師閱讀的選擇。
這本書用非常多的實例示範 GoF原始的pattern，並且盡可能詳細的解釋每個pattern的意義與用途(呃，可惜factory method這章講掛了，大概寫到這章時作者已經沒力了所以草草帶過，這部份可從其它書裏補齊)，更重要的是 ch16. The Analysis Matrix 裏面介紹了一種系統化的pattern-based OOA/D手法，透過matrix 表格的分析可以快速的瞭解那些pattern可能有助於解決眼前的問題，看完這章就覺得值回票價(當然前提是得先對前面15章講過的每個pattern都熟悉才會比較有感覺。)
簡單整理一下目前用flash進行RIA專案開發最常用到的pattern：
MVC
Observer
Delegate
Facade/Adaptor
Singleton
Abstract Factory
Facotry Method
Strategy
Decorator
Object Pool
這是依重要性、常用性與相關性所分組排序的，裏面有些名詞或許聽起來很神祕(例如 Facade, Factory Method, Object Pool…)，但實際這些東西可能早就在日常的actionscript coding中一用再用而不自知。
例如 facade幾乎是每個class 的 API(最簡單的例子可看mm版的元件實作手法)都會套用，factory method則是像 collection, recordset, dataset裏的 getIterator()必備的手法，而Object Pool則是用在 xml/web service connection或 flashcom server的連線管理或自製的 database connector。
至於像observer其實就是 addEventListener/DispatchEvent這樣的指令，只是macromedia已經實作好class讓工程師直接用即可，在colin moock的EAS2 裏有一章就是自已實作這個pattern，不過因為功能並沒有太強大或特別不同，因此教育意義遠高於實用價值。
附帶一提，看完這本書後去amazon上查了一下書評，結果發現第一版居然狂賣二十幾萬本，等於就是各大專院校的教科書，實在是很神奇啊~想想看同樣的書如果用中文寫成在台灣(或整個中文世界)能不能賣到二萬本？這點或許可以從趙英傑翻譯的ASDG2與EAS2 以及香港Luar的RIA書的銷量就可看出個大概 (哀~).
| by admin
Next Posts
Previous Posts
