什麼是物件

摘要:什麼是物件

物件

  常常聽到有人在談論物件導向,那到底甚麼是物件導向? 就我個人理解而言,首先我們要先弄懂甚麼是物件,就我個人理解來說:「物件的是一個個體或是一個元素,以系統角度而言,就是依據系統包含的一切現實狀況中的任何物體,基本上都可以稱是一種物件」,簡單的說就是「Everywhere is Object」任何東西都可以是物件,既然任何東西都可以是物件,那物件的 SIZE 就很難去定義,因此實際在做系統分析與設計時,必須要依據現實狀況的概念來設定物件,並且要使用解決系統問題的角度來去決定。例如以一個流程管理而言,會有許許多多的表單,例如說「請假單」、「出差申請單」、「採購單」、「採購明細單」到真實在做系統分析與設計時,就應該要出現一個物件叫做「請假單」、「出差申請單」、「採購單」以及「採購明細單」,在簽核的流程中,會有許多的角色如「總經理」、「課長」、「組長」...等,而實際設計的狀況下,就應該要含有這些角色的物件(當然角色可以視狀況來定義,或許可以是一個屬性,但應該要是一個屬性的物件)。

物件定義

  以J.Martin、J.Odell兩位大師對物件的定義:

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

  當然這個個體就像剛剛有提到的他的SIZE就變得比較難去定義,因此我們對他做了一些定義:「就以單一物件而言,它僅僅就只能有單一的相關作業職責,在設計該物件時不能也不應該參雜有多項不相關的功能。」基本上就是一個物件只會有一個功能概念 (Concept),就已剛剛提到的「出差申請單」的例子,「出差申請單」就是員工接收到出差的需求時,所提出來的一張申請單,他的功能概念就是要向上級申請出差作業時所需要的一個依據,因此「出差申請單」該有的屬性與方法就只是單純的「出差申請單」,不應該包含有別種功能,例如:出差費用申請...等。

  但是事實上規則並不會如此的死,因為它的存在是定義在一個功能概念,也就是這功能概念是可大可小,而功能概念大小還是要依據專案類型來作區分,也就是依功能型來做區別,例如說:我接到的專案是一個「行車管理系統」,主要功能是要監控車輛行駛狀況,就片面字語上來看,會有一個的物件是車子,而本系統是一個行車管理系統,因此最小的單位就單單是車子,所以輪子、儀表板、引擎...等都只會是這個車子的屬性,甚至不需要去定義這些屬性,另外有一種車輛叫做聯結車,他的車體可以是一個車頭物件加上一到兩截的車廂物件,也可以是一個聯結車物件,有車廂數量的屬性。

  而如果我們接到的案子是車輛組裝廠的生產管理系統,那最小的單位或許就需要定義到每個車體的零件,因此剛剛提到的引擎、輪胎、儀表板,都會是一個一個的物件,因為他的Concept就是一個引擎、輪胎或是儀表板,還有可能會有車頭的物件,而車頭中,可能就會包含有引擎、儀表板、輪胎...等等,因此要設計一個物件,主要還是看系統的需求,以及現實中所需要的大小,來定義出一個物件的大小,不過他都不脫離一個規則,就是他只會有一個Concept,如果出現一個以上的Concept,有可能就出現了物件混淆的問題,舉剛剛案例來看,一個引擎的 Concept 應該是要控制感應器拉桿拉多少的時候,要加入多少油,到引擎中產生爆炸力,而產生玩爆炸力之後如何會牽引車子移動應該是輪胎、區軸感應器的物件所負責的Concept,要加入多少油到引擎中是引擎物件所控制的,然而剩下多少油,這就應該是油箱的物件中去做管理的,因此在設計引擎物件時,就不應該將其他不相干的Concept 也納進來到引擎這個物件中,讓他只單純處理某一項作業職責就號。

Object Instance

  而談到物件,經常性的會連帶談到物件實體(Instance),對我的解釋來說,物件剛剛已經有提到過,而Instance就好比是這個物件的靈魂,以崑崙神話來看,我們程式設計師就好比是女媧,當女媧來到了大地之後,覺得在世界上應該要有一種可以主宰世界的動物,因此就將泥巴攪和水,用心捏出了一個人的形狀,並且賦予這個人的一些能力(方法)、與外觀(屬性),因此人類這個物件就因此而產生了,而當他對這個泥巴,吹了一口氣,人類救活過來了,就好比我們對這物件配置了一塊記憶體空間給他,也就是這個物件的實體。