分類: 程式設計

將 具有共同特性(包括屬性與操作)的一群物件的集合(sets)，抽象化後稱之為類別(class)。分類可以說是物件導向的本質，因為這是解決軟體複雜度 的最根本道理，軟體設計者將物件 “分門別類”，才能層次分明、井然有序的管理好在系統內各司其職、各負其責的眾生物件，也因為系統就是藉由各類型物件的互動、分工合作，才能完成越來越形 複雜、所被賦予的一個個工作與任務。

那麼，又如何作分類？ 分類其實是萬物與生俱來的本能。例如，看到電子琴、吉他、笛子等物件，自然而然就會聯想它們都是屬於 “樂器” 這個類別。那麼，電子琴是否也可以視為是單獨的一個類別？ 當然可以！ 當你想區別 “電子琴” 這個類別與其它也是屬於樂器、但卻又有個別的特色，如 “吉他” 類別時，就會將 “樂器” 這個類別再細分至 “電子琴”、”吉他”、”笛子” 等類別。當作了更細部的類別界定後，當你看到 “老賴家買了一部 Yamaha 電子琴”，就會知道這個物件是屬於 “電子琴” 這個類別，而不會是 “吉他” 這個類別了。另一個例子，跑去 “阿珠貓狗鳥兒專賣店”，你會看到 “各類” 的動物，然後，你會想成牠們 “都是”(抽象化) “寵物”(共同的類別)，但，你該不會稱這些動物為 “禽獸” 吧？ 這也代表著，分類會依據普遍價值觀的概念，找出適當的術語，來為其分類。

只有人類會分類嗎？ 前述提及，分類絕對是萬物的本能。例如，跑去六福村隔著巴士車窗看一大群狒狒們，牠們會聚在一起，然後也隔著車窗看著你，如果你敢打開車窗，甚至跑出去，這些狒狒們鐵定會 “毆打” 你，因為牠們知道你是 “非我族類”，是兩種區隔明確的類別。

是 否可以對類別作明確的定義與描述？ 依據 J.Martin & J.Odell 的 “概念三部曲(concept triad)”，可以利用三角形的圖形表示法，將類別以內涵(intension)與延伸(extension)兩種表達方式，來作更為明確的定義及描 述。例如，要解釋與定義 “車子” 這個類別：

“車子是可以在陸地上行進及載人的交通工具。”
“腳踏車、摩托車、汽車、巴士、坦克車 …等，都是車子的一種。”

① 是以定義的方式來表達類別，這樣的方式稱為 “內涵(intension)”； ② 則是以實際的實體為例，來說明類別，這樣的方式稱為 “延伸(entension)”，兩者都是類別的表示法，以 “概念三部曲” 的表達方式如下圖。

既 然，主流的程式開發語言，包括 Java, .NET(C#, VB …) 等，甚至連 PHP 這種 ”Script-based”，以網頁設計為主的描述性語言，都已標榜能實現所謂的 “物件導向(object-oriented)” 的開發模式，那麼顯然，軟體分析與設計、包括程式撰寫人員，都必須要能對以 “物件” 為單位的設計與開發，要能有其共識。但 “物件” 卻往往很難被界定與定義，具體的東西，如電腦、小狗、汽車、杯子、Xbox 360 …等，都是物件；但抽象的概念，如訂房、會議、訂購、保險、行動電話的簡訊 …等，也都可以是物件。具體的東西， 因為能看得到，所以看起來比較容易能找出 “物件”，但其實也很容易有 “茫點”，例如，”松樹” 是一個物件，還是多個物件？ “樹枝”、”樹葉”、”樹幹”、”樹根” 是 “松樹” 的基本組成元素，它們是否也可以算是物件？ 而抽象的概念，更是難以界定，若沒有足夠的抽象能力(抽象能力有時又要帶點創意與想像)，實在很難捕捉看不著、摸不到的 “相”，將之定義為具體的(specific)物件。

“到處都是物件(everywhere is object)”，但沒有細心觀察與體會，以及把握最基本的判斷原則，並不容易發掘出對未來軟體設計時有助益的物件。什麼是最基本的判斷原則？ 依據 J.Martin & J.Odell 對物件的定義：

“An Object is anything to which a concept applies. It is an instance of a concept.”
(物件是概念可以被應用的任何事物，它是概念所呈現的個體)。

由 此定義也可以得知，“物件” 與 “個體(instance)” 這兩個術語，其實是具同義詞性質的。將 “概念(concept)” 作為認知的對象時，所產出的 “個體(instance)” 即為物件。但概念會牽涉到人們對於觀點、角度等認知，而會有不同的體認。例如站在遊客的角度，他所看到在森林裡面的樹木，是一個個的 “個體”，會從樹木之外的角度來欣賞樹木的茂盛與宏偉，是一種整體性的認知；但站在植物學家的角度，他要研究組成樹木的結構元素，所以會把樹木分為 ”樹幹”、”樹枝”、”樹葉”、”樹根” 等多個組成樹木的 “物件”，從結構的觀點來研究樹木的內部組成。

這同時也就代表了，雖然到處 都是物件，但並不是任意地將物件給 “塞” 入軟體系統內，物件導向的設計，是將問題領域(problem domain)的概念，呈現與對映(mapping)至軟體系統內，那麼，如何正確地捕捉(capture)問題領域的概念成為物件，就成為是軟體設計 中，最為重要的技能與素養了。

例如，從業務操作人員(operator)最常溝通的術語，“訂購單(order form)”，軟體設計人員若不知如何正確捕捉概念術語，結果將 “訂購單” 視為是一個單一的物件，而將其設計至 “領域模型(domain model)”，乃至於 “軟體規格模型(software specification model)”。但，若是懂得從不同觀點與角度來觀察與思考的軟體設計人員，會發現到 “訂購單” 其實是一種 “UI(User Interface) 的呈現”，未來在軟體資訊系統中，是以如 “Web Form” 等實作技術來呈現訂購單的相關組合資訊(information)，當分析 “訂購單” 的內部結構時，就會找出更具 “本質性(essential)” 的概念物件，包括 “訂購(order)”、”訂購細項(order lineitem)”、”項目(item)” …等確實能充分表達概念的物件。(往往這些概念物件，會成為資訊系統中間層(middle-tier)的企業物件(business object))。