物件導向設計的方式,強調的是直覺易懂的方式,貼近實際的狀況。所以在命名的時候,多以貼近實際的名稱來做為物件的命名。
當然,如果要討論到 UML,則超出本系列與本人的層級了。更何況,沒有像 Rational Rose 或 ALM(Application Life-Cycle Management)之類的物件導向建構工具,UML 也只是流於紙上作業,或許對分析上有用處,但並沒有享受到整體開發上的好處。(僅個人觀點)
所以,本篇要介紹的,一樣是相當基本的建構步驟。
.決定物件及其屬性
要決定系統中要有哪些物件,首先要瞭解我們要解決什麼問題,以及會面對的對象(可能是員工、客戶、帳單等等)。決定好物件之後,我們要賦予每個物件的內部屬性(屬性是指我們會用到的資訊,如果不知道怎麼下手,那把帳單拿來看一下吧!)。如:帳款總額、客戶姓名、帳單日期等等),多練習幾次,就可以漸入佳境。
.決定物件的動作
例如帳單金額的結算、更改帳單地址、列印帳單等等,這些都是我們決定物件動作的一些思考方式,動作定義出來,就可以依據屬性的內容進行相關的運算動作,並將結果記錄到另外的屬性中,這都是物件設計時常會運用的方式。
.決定物件間的關係
如果我們設計的只是單一物件,那麼也不需要做什麼管理,直接拿來使用即可。但是,如果我們定義了很多物件,而個物件之間又有其相關性時,物件之間的管理,則就顯得重要了。利用開方工具提供的 Class Diagram 來管理物件,是一個不錯的方式,而且可以看出物件之間的交互關係。
.決定物件可公開的資訊
決定物件所提供的公開資訊(宣告成 Public),可以保護內部資料不會受到外界的干擾,或只能透過公開的界面與內部資料溝通。對於使用物件的人來說,則不用負擔過多的資訊,達到 Information Hiding 的目的。
.決定每個物件的界面
這部份其實是最難的部份了,因為不好定義。還好以目前的程式語言,是可以忽略掉這一段的。因為如果我們沒有定義 Interface,Compiler 會自動幫我們產生 Interface 的定義出來,我們的程式,基本上都是實際的 Implement。
物件的設計,並不是一次就到位的,他可能隨著程式的發展,或需求的變更,不斷的演進或更動其內容,重點就是貼近真實的情況。也比較不會有系統發展到最後,跟原來的樣貌差距很大的情況發生。
當然,如果要討論到 UML,則超出本系列與本人的層級了。更何況,沒有像 Rational Rose 或 ALM(Application Life-Cycle Management)之類的物件導向建構工具,UML 也只是流於紙上作業,或許對分析上有用處,但並沒有享受到整體開發上的好處。(僅個人觀點)
所以,本篇要介紹的,一樣是相當基本的建構步驟。
.決定物件及其屬性
要決定系統中要有哪些物件,首先要瞭解我們要解決什麼問題,以及會面對的對象(可能是員工、客戶、帳單等等)。決定好物件之後,我們要賦予每個物件的內部屬性(屬性是指我們會用到的資訊,如果不知道怎麼下手,那把帳單拿來看一下吧!)。如:帳款總額、客戶姓名、帳單日期等等),多練習幾次,就可以漸入佳境。
.決定物件的動作
例如帳單金額的結算、更改帳單地址、列印帳單等等,這些都是我們決定物件動作的一些思考方式,動作定義出來,就可以依據屬性的內容進行相關的運算動作,並將結果記錄到另外的屬性中,這都是物件設計時常會運用的方式。
.決定物件間的關係
如果我們設計的只是單一物件,那麼也不需要做什麼管理,直接拿來使用即可。但是,如果我們定義了很多物件,而個物件之間又有其相關性時,物件之間的管理,則就顯得重要了。利用開方工具提供的 Class Diagram 來管理物件,是一個不錯的方式,而且可以看出物件之間的交互關係。
.決定物件可公開的資訊
決定物件所提供的公開資訊(宣告成 Public),可以保護內部資料不會受到外界的干擾,或只能透過公開的界面與內部資料溝通。對於使用物件的人來說,則不用負擔過多的資訊,達到 Information Hiding 的目的。
.決定每個物件的界面
這部份其實是最難的部份了,因為不好定義。還好以目前的程式語言,是可以忽略掉這一段的。因為如果我們沒有定義 Interface,Compiler 會自動幫我們產生 Interface 的定義出來,我們的程式,基本上都是實際的 Implement。
物件的設計,並不是一次就到位的,他可能隨著程式的發展,或需求的變更,不斷的演進或更動其內容,重點就是貼近真實的情況。也比較不會有系統發展到最後,跟原來的樣貌差距很大的情況發生。
推文( 1 )

