(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
如果我是某大軟體公司的主管，要應徵軟體結構性的設計人員 (偏對技術性，而非需求分析)，一般的職稱是稱之為 系統設計師 (SD, System Designer)，或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等，那麼，我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已，一點意義都沒有。 要背書的話，不如直接給個電腦上網，然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤，相對來說，一個標籤可以有一到多個書籤。 另外，標籤是不會含有子標籤 (Sub-Tag) 的。
如果我要改良 Google 書籤的設計，希望能再加上 "資料夾 (folder)" 的管理觀念，也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一)，而某一個資料夾可以擁有一到多個書籤，同時資料夾也能再包含子資料夾 (Sub-folder)。
同樣類似的應用，可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。
請你利用 UML 類別圖，來表達出關於 書籤、標籤與資料夾的結構關係，並簡單說明你的設計想法。
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
這張設計圖該如何解讀呢？
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
4. 最佳化程式碼的重複使用.就像System.Collections.Generic.List<>來說, 在經過最佳化之後的集合類別, 可以提供給任何型別來使用, 不必再自行定義多組特別型別的集合.5. 不只是集合.雖然上例提到的多是集合的用法(這也是Generic最好發揮之處), 但無論是interface, method, parameter, delegate..., 只要有需要, Generic都能幫助我們做好該做的事.若再進一步, 讓Generic與Reflection結合在一起, 所產生的威力更是強大. 例如將它們套用在Factory Pattern中, 或是應用在ORM中, 用以產生persistence object.無論如何, 在有Generic的世界, 不去善用它, 就像是自廢武功一樣. 當然, 我們的前提是使用泛型時必須經過良好的物件導向設計, 分析出需要Generic的場合, 而必須避免over design, 將一切都給泛型化.
