[WPF Documents 之旅]System.Windows.Documents下的Class Diagram
周銀輝
由於工作和個人興趣需要，開始學習WPF中的“文檔”（FlowDocument, XPS...)。
學習一種新的東西一般有兩條路線：
一種是先大概瞭解一下，然後“帶着問題去學習”，比如需要遇到某個問題搞不定時就開始翻文檔，翻Google，然後把問題解決並且學到了新東西。
另外一種方式，在動手解決之前，把基礎知識都搞紮實，然後胸有成竹地去面對問題。
這各有利弊，前者避免了“學習的東西太多”的問題，但解決問題時難免有些“頭疼醫頭腳疼醫腳”，並且在尋求答案時會變得比較盲目，或許類庫中本來就有相應的方法或稍稍變通一下就可以搞定的，自己卻始終想不到，其實，說白了，除了一些特殊行業外，靈感更容易來源於紮實的基礎、豐富的經驗而不是聰明的大腦。並且幹一段時間以後自己終於明白：哦，沒有系統學習。所以個人更偏向於後面的一種學習方式，這得益於學生時代的學習習慣：在完成家庭作業之前，先花一個小時將老師講的內容認真複習一遍，以便更爽快地把作業搞定，而不是被作業搞定。別擔心學習量太大，因爲知識是分塊的，比如WPF的東西很多，你不可能將WPF全部學習完成之後纔去幹活，但至少在搞定一個Button之前，你應該將Button的各個屬性，方法，事件理解一遍，而不是當用到某個方法時纔去查（並僅僅查）那個方法的用法，如果這樣，你很難搞懂一個Button到底能幹啥不能幹啥。
我們平時常常說“開發帶動（驅動）學習”。我們作爲“被驅動者”有兩種行動方式：
一是消極方式（比較常見），學習並僅僅學習（查閱並僅僅查閱）開發中需要用到的東西，將問題搞定後便結束了。一個簡單的例子：你要負責顯示一個WPF窗口，所以你查閱資料，知道應該調用Show（）方法，所以你學到了Show（）方法。而ShowDialog（）方法呢，也許下次遇到需要用ShowDialog（）方法來解決開發問題時你會去查閱，而沒有這樣的開發問題的話，則永遠不會知道，那麼你能在你的簡歷中寫上“熟悉WPF” 或“2年WPF開發經驗”這樣的字樣嗎？在面試一些朋友時常常遇到這樣的尷尬局面:
我： 看你簡歷中提到了XXX技術，我們能簡單聊聊嗎？
朋友：以前公司有個項目用到了這個技術，然後有兩年多的時間一直在用。
我：那麼能談談其中的YYY嗎？
朋友：哦，不好意思，好像聽說過，但我們這個用得比較少...
二則是主動地學習，項目用到這個東西，那麼它在提醒你：這個世界上存在這樣的東西（也許你以前從來沒有聽說過），並且這個東西能解決現實中的某一類問題，這是又一個將個人成長和團隊產出結合起來的最佳機會，這是學以致用的最棒方式，或許你還會想到更多。當說到這裏，不用我說太多，你已經能夠想象主動學習應該是什麼樣子的了。
廢話了這麼多，於是在學習WPF 中的Document之前，繪製一張類圖也就不足爲奇了（由於涉及的類比較多，類圖比較大，整張圖可以從文章附件中取得，大概樣子如下：）
下載整張類圖 ： http://files.cnblogs.com/zhouyinhui/DocumentsNamespace.zip （該類圖用Visual Paradigm for UML 6.4 Professional Edition編輯，你可以到這裏下載試用版：http://www.visual-paradigm.com/product/vpuml/）
另外，下面這張來自於MSDN文檔的TextElement內容模型也很具有參考價值：