淺論「什麼是物件(Object)?」

既然,主流的程式開發語言,包括 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))。

物件的特徵(features)

既然物件是概念的具體呈現,那麼,每一個物件,必然有其特徵(features),而可以讓外界能辦識它。物件的特徵,包括兩個部分,屬性(attribute)與行為(behavior)。
“屬性” 就是物件所具有其特定的型態、形狀、性質等。以 “書本(book)” 物件而言,其屬性可能就具有書名、作者、年份、出版社等性質;以 “訂購(order)” 這個抽象的概念物件而言,其屬性可能就包含訂購日期、時間、地址、訂購方式、數量等相關資訊。

“行為” 就是物件能 “做” 的動作。以 “車子” 為例,利用鑰匙開啟會讓引擎發動;踩油門會讓車子前進;轉動方向盤會讓車子轉彎;煞車會讓車子停止。這些動作,就可以視為是 “車子” 所特有的 “行為”。在軟體規格模型中,行為則稱之為軟體物件的 “操作(operation)”;在程式語言中,則稱之為 “方法(method)”。

資訊隱藏

屬性代表的就是物件所知道的資訊,它有權利來決定是否哪些資訊可以被外界來取用(access),所以對於物件的屬性,一般會設計將之給 “封裝(encapsulate)” 起來,不被外部來窺視,這樣的作法稱之為 “資訊隱藏(information hiding)”,外界要能存取該物件的資訊,則需先經過該物件的 “同意”,然後傳遞 “訊息(message)” 給想要取得資訊的物件,藉以從外部取得標的物件的內部資訊。舉例而言,王小明想約可愛的長今喝咖啡,因為不知道長今的想法,所以會問長今說:「我們今晚一起去喝杯咖啡如何?」,長今回問:「去哪裡喝咖啡呢?」,王小明回答:「小貓咖啡坊,好嗎?」,長今回答:「好的 ^^」,這時王小明總算才得到長今的答案。這兩個物件之間的互動,參考下圖。

範例—物件之間的訊息傳遞
圖、範例—物件之間的訊息傳遞

文章導覽

   

共有 3 則迴響

  1. Yes, 士官長解釋的是這樣沒錯。
    不過,還請記得,我是訂購,我需要提供 “服務” 給客戶,所以,需要提供
    “計算訂購總額”、”取得訂購資訊” 等行為。

  2. i’m Transaction

    i know Transaction LineItems / SubsequentTransactions

    so i can

    CalcOverLineItems
    CaleOverSubsequentTransactions

    and more …

  3. ==>以 “訂購(order)” 這個抽象的概念物件而言,
    ==>其屬性可能就包含
    ==>1.訂購日期、
    ==>2.時間、
    ==>3.地址、
    ==>4.訂購方式、
    ==>5.數量
    ==>等相關資訊。

    那…請問一下:
    如果這五點是”訂購(order)” 這個”抽象的概念”物件的”屬性”
    那”訂購(order)” 這個”抽象的概念”物件的”行為”會是什麼?
    “填(fill)”?

發佈回覆給「Steven」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *