My friends, my life, my style - James S.F. Hsieh

8/31/2009

[OOAD] 一個複雜系統中的五種屬性 Part3

Separation concerns - Decoupling
一個系統不管在相同或不同層次下, 都存在可分割拆解的部分, 這些分解於不同部分的單元之間有著較低至沒有的耦合性, 分在相同部分內的單元則有著較強的耦合性. 舉個例子: 一輛汽車有許多的功能粗略的分割, 我們可以得到車輛的骨架鋼板, 傳動, 電力, 空調, 音響, 安全等較相互獨立的子系統, 子系統間有著較弱的耦合. 譬如汽車的傳動系統利用電力系統來發動內燃機, 而電力系統利用傳動產生的動能來發電, 彼此之間有著交互關係, 但相依性遠低於子系統內各單元間的關係, 譬如說傳動系統中有變速箱, 離合器, 內燃機等, 這多個單元之間的耦合性就遠比跟其他子系統之單元來的強烈.
這種特質是複雜系統中都可以觀察到的性質, 而這個性質有利於簡化系統的複雜度. 為什麼要簡化複雜度呢, 主要的原因在於人們無法同時處理太過於複雜的事物, 我們必須要有些前提, 假設或是模型來降低系統的複雜度並且把焦點放在當下要解決的問題之上, 讓彼此耦合較弱的單元分離可以有助於我們分析與創建一個系統.

為什麼這些前提, 假設或是模型可以幫助我們發展一個系統呢? 以認知心理學的角度來看, 人們同一時間下能處理的資訊量跟短期記憶是有限的, 在同個時間下一個人大概只能記住5~9 個 chunk, 基於這個原因, 我們必須簡化或抽象畫我們的問題並且忽略細節才有辦法思考,  正所謂 "分而治" OOP 中的封裝與多型就是建立在這種思維之上.

小朋友吵架 蝦密 蝦密 蝦密

8/30/2009

寶貝的優點

寶貝的優點 1. 你的毅力 執著 與 特定目標的專注力 2. 你的可愛美麗與氣質 不管是外表或內心 3. 你的貼心與溫柔 4. 你的能力比其他女生都好更勝過不少我認識的男生 5. 你對待朋友的真誠還有熱情很會照顧人 6. 你的善良 跟 憐憫心 你會將心比心 7. 你對家庭的照顧與關懷 8. 對工作的積極還有上進心 9. 賢慧 會做家事 東很多稀奇古怪的東西 10. 跟我一樣喜歡大自然與復古的心

8/29/2009

2009 08 29 上磺溪

8/24/2009

[OOAD] 一個複雜系統中的五種屬性 Part2

Relative Primitives
我個人解釋是, 一個系統該有怎樣相關的元素幾乎取決於系統的觀察者對系統的描述, 軟體是個憑空產生的東西, 人們在思考一個需求並轉換成一個系統時有著高度主觀的見解與考量, 這也造就了軟體設計的複雜度.
舉個例子: "設計出一個可以讓人們涼快的器具", 人們可以設計出扇子, 電風扇, 冷氣機, 而即使是扇子這樣簡單的器具, 都可以有多種不同的設計方式, 而這些東西都源自於相同的需求.
我認為, 設計者對於需求的詮釋是個決定性的因素, 因為一個需求包含了許多潛在性的根本需求, 包含功能面與非功能面, 以上述的例子來說, 扇子跟電風扇有著相近的原理, 都是利用流動的空氣來帶走熱能, 差異之處在於電風扇不需要 "人力", 這個功能可以說是非功能性的考量或是延伸的需求: 利用電力來讓扇葉轉動是比較有效率的, 或是, 我需要一個不需要出 "人力" 就可以達到散熱的工具.
軟體在這方面的複雜度就非常的高, 但是這些潛在需求或是非功能性的需求往往都會被忽略, 原因無他, 因為這些東西對於外在的使用者是看不見, 但是軟體是會藉由版本的更新而演進的, 在演進的過程也有著適者生存與無法從頭的特性 , 而演進的彈性與可能性幾乎取決於最初的觀察者對系統的觀察與需求的分析 (可參考 Architectural Vision) 可惜, 多半的觀察者都會過度簡化該需求或是做出只符合當下需求的設計.

[OOAD] 一個複雜系統中的五種屬性 Part1

以下是由書本 Object-Oriented Analysis and Design with Application 摘錄出來的幾個標題
Hierarchic Structure - System, Subsystem SubSubSystem, SubSubSubSystem
每套系統通常都有自己的 Hierarchy, Hierarchy 可以有多種層次與面向, 它的設計或是自然的產生通常包含了某種原因, 主要的目的我認為有數個:
  1. 容易讓人理解: 因為每一種層次會有自己特定的責任, 被設計成只處理特定性的問題, 所以我們可以用一些邏輯性的的假設與抽象性的推論在根據系統的結構快速的了解整個架構的運作方式
  2. 降低相依性: 相同層次可以分成多個子系統, 之所以可以分離就是因為它們通常毫無關係所以可以被分離, 而不同層次的子系統間也因為責任的分層化而隱藏了細節與降低了相依性, 將低相依性自然衍生的就是彈性與可抽換性
  3. 複用性: 越單純的東西越具有複用性, 越複雜功能越強的東西複用性愈低, 一個系統的功能是由多個單純的子系統互動產生的結果, 該系統也可以成為別人的子系統. 一系統包含完成這個功能性的主要邏輯與流程, 而子系統只是參與互動的角色, 對於該邏輯與流程的耦合度較低或完全無耦合度, 所以子系統可以保持較高的複用性.

8/22/2009

COM IDispatchEx and .NET IExpando

IDispatchEx Interface 用於 Dynamic run-time models, 因為原本的 IDsipatch 只能靜態的 Dispatch 固定的行為, 舉個例子, 某個 COM 定義了數個 Method 與 數個 Property 並且實做 IDsipatch, 而Dispatch 的過程必須透由 IDispatch::GetTypeInfo 取得對應的 ITypeInfo 查詢 dispID, 然後在使用 IDispatch::Invoke 產生呼叫的行為, 重點在於 TypeInfo 通常是固定的, 實做上, 同常是使用LoadTypeLib API 去載入對應的 TLB (TypeLib 由 IDL 產生) 產生出對應的 ITypeInfo, 而 Dispatch 在經由相同的 ITypeInfo 來得到 Invoke 所需要的引數資訊與 VTable offset, 進而造出對應的 callstack. 對 Callee 而言整個 Dispatch 行為都是由 compile time 所完整定義, Caller 只是在執行時期動態的找出需要呼叫的 method 然後 dispatch . 有興趣可以參考 Creation of Dispatch API Functions
而IDispatchEx 是建立在 ITypeInfo 能夠在執行時期動態改變的概念上去設計的, 所以我們可以看到 IDispatchEx 是沒有接露 GetTypeInfo 這種 method 的, 而是利用 IDispatchEx::GetDispID 即時的去查詢對應的 dispID, 因此, IDispatchEx 就有能力用任何方式組裝或 binding 新的 member function 或是 property 並且讓 caller 去呼叫. IExpando 是相對應 .NET 版本的介面, 有趣吧 :)

8/20/2009

你覺得這些 Multi-touch 的軟體如何?

http://www.theinquirer.net/inquirer/news/1495987/windows-multi-touch-video-demo

Windows 7

Windows 7 RC 才剛結束不久緊接著 Windows 7 要 shipping 了, 相信用過 Windows 7 的人都感受過他的速度, Windows 7 在 start-up 速度方面相較 Vista 有著顯著的改善, 而 boot後也可快速的進入比較穩定的狀況 (Vista 大約要 3~5 分鐘而 Win7 大約是 2 分鐘). 在記憶體使用量來說, Win7 也許是改善了 Superfetch 的快取策略, 開機後的記憶體使用量遠比 Vista 低的多. 當然還包括 UAC 的改善還有少量 Shell 上的變動. 在某個層面來看 Win7 似乎是改善了大眾對 Vista 的抱怨, 關掉或分割了某些功能減少對使用者的不便與打擾增加一點點的新意, 還有改善對新硬體的支援. 骨子裡 Win7 就是 整骨過的 Vista 或是簡化版的 Windows Server 2008, 你願意花錢升級 Win7 嗎? (使用盜版當然無痛, 但是正版的使用者可是所費不貲)

看到了 PC World:不升級到Windows 7 的七大理由 的評論, 其中最有趣的就是 "Win XP 已經夠用了" 這項理由, 還記得 XP 在 2001 年帶給你什麼嗎 (其實 NT3.51 1995 就很好用了)? 對微軟來說 XP 是具有重大使命的一項產品, 他使用了 Windows 2000 以 NT 為基礎的穩定核心 , 接軌了人們對 Win98 WinME 的使用習慣與背後龐大的軟體群. 簡單說, XP 包含了一個成功的作業系統該有的多個基本元素: 穩定, 少負擔, 熟悉使用者介面與使用模式, 還有當代沒有可取代性的其他 Win 產品. XP 可以說是符合基本使用者的 "甜蜜點", 這也是為什麼 2006 年市佔率可以有 85.3%, 當下連 Vista 都還無法取代的主要原因. 那麼下一世代的作業系統應該還包括什麼呢? 直到目前為止 Win7 還是沒有給人劃時代的感受.

給我的印象 Win98 = 當機, WinME = 搶錢, XP = 夠用, Vista = 太肥, Win7 = 由大家來評斷吧 :)

有趣的是 Win7 提供了 Windows XP Mode 喔... 這意味著什麼呢? Coming Soon: Windows XP Mode and Windows Virtual PC

8/16/2009

有人暗戀我ㄟ~~ (羞)

8/11/2009

To Love You More 恋人よ

8/10/2009

Default UnhandledExceptionFilter and KiUserExceptionDispatcher

我相信以下的 Dialog 在 XP 下是常見的, 任何一個程式在 Crash 的時候基本上都會顯示這個基本且不親切的 DB, 你曾想過, 當這個 DB 顯示時我們還有機會看到 Crash 的確切位置嗎? 其實是可以的喔!
當這個 DB 出現時, 我們可以使用 WinDBG 去 Attach 這個已經 Crash 的 Process 或是開啟對應的 Mini dump, 並且在屍體中找到對應 Crash 的 thread! 以下圖為例, 我們可以看到這個 thread 的 stack 中有去呼叫一個特定的 UnhandledExceptionFilter! !findstack kernel32! UnhandledExceptionFilter 這個 DB 就是由該函數負責產生的, 而該 function 則是由 KiUserExceptionDispatcher 所分派執行, KiUserExceptionDispatcher 的目的是要找尋能夠處理 Exception 的 ExceptionFilter, 而 UnhandledExceptionFilter, 則是系統預設的 ExceptionFilter, 該 Filter 則"掛"在 BaseProcessStart 或是 BaseThreadStart 當中 所以我們可以預期這兩個函數有這樣對應的程式碼:
__try { ..... } __except(UnhandledExceptionFilter(GetExceptionInformation())) { // ExitThread or ExitProcess }
所以我們可以判斷 stack 中呼叫 KiUserExceptionDispatcher 的前一個 Frame 就是程式中實際 Crash 的點! 而該程式就是 Crash 在 Console!wmain 當中. 更進一步的, 我們可以根據 KiUserExceptionDispatcher 傳入的引數來得到 EXCEPTION_RECORD 跟 CONTEXT 結構, 進而得知 exception 的種類與確切 crash 的 eip.
VOID STDCALL KiUserExceptionDispatcher(PEXCEPTION_RECORD ExceptionRecord, PCONTEXT Context)