鄉親阿...J丟喜愛歹玩阿...
close
原文：物件導向實例 – 是定理還是方法
以下從裡面截取一些文章內容出來...
....
從上面的推演結果，相信讀者已經認可筆者的假設是可以獲得成立的，也就是說 VB 是支援 OO 的程式語言。嗯！這樣的說法相
當弔詭，而且在理論基礎上也有些牽強，不過本文撰寫的目的，不是要賣弄詭辯之術，而是要藉此機會向各位讀者說明，其實物
件導向程式設計是一種『設計的方法』、一種『思考模式』而不是一種『定理』。
....
從上面的範例中，相信聰明的讀者已經感受到同樣的程式，不同寫法之間的差異了。不過這些差異雖然對於使用者而言，是完全
感受不到它們之間的不同所在。對於毛主席而言，不管白貓或者是黑貓，也是只要會抓老鼠的貓，就是好貓，但是對於程式員在
作法上，差別影響就很大了。因為一支有條不紊的程式，總是比較容易維護。當然，對此有些人可能會不服氣，並且強調這是個
人程式撰寫的風格問題，但是筆者要強調的是，撰寫程式原本就是希望要迅速有效的為客戶解決問題，而不是在玩『記憶金庫』
（註 1）這樣的遊戲，當然更重要的是，程式要讓別人看的懂，這樣才可以提升軟體的價值，而使用 OO，也正是它提供方法來
達成這樣的目的。所以討論到這裡，我們可以回應本文之初所描述的那兩件事情，那就是：雖然 VB 普遍不被人認為是屬於OO
的程式語言，但是事實上，使用 VB，我們還是可以很 OO 的；同理，既使我們用的是 OO 的程式語言，例如 C++、 Java 等
程式語言，一樣可以寫出很不 OO 的系統出來。其中的關鍵，就是程式員是否真的具有 OO 的概念。
....
記得筆者之前所說的物件導向程式設計，是一種設計的方法，一種思考的模式嗎？剛剛筆者的演繹，只是示範了物件導向的設計
方法，而物件導向的思考的模式，則又是怎樣的一回事呢？我們以一個範例來說明：
現在我們預備撰寫一部西遊記的遊戲，其中的角色包括唐三藏、孫悟空、豬八戒以及妖怪等。然後在遊戲之中會遇到過河，以及
遇到妖怪等事件，在傳統的思考模式之中，系統通常會用切割成下面的樣子。
西遊記主程式。
過河。
遇到妖怪。
妖怪遇到三藏師徒。
其中過河部分會包括三個步驟：
如果唐三藏過河則划船。
如果孫悟空過河則用飛的。
如果豬八戒過河則用游的。
而三藏師徒遇到妖怪也會分成三個步驟：
如果唐三藏遇到妖怪則念經。
如果孫悟空遇到妖怪則斬妖。
如果豬八戒遇到妖怪則大喊救命。
而妖怪遇到三藏師徒也會分成三個步驟：
如果是唐三藏則吃掉。
如果是孫悟空則逃跑。
如果是豬八戒則戲弄他。
然而在物件導向的思考模式下，系統通常會用切割成下面的樣子。
系統主程式。
唐三藏。
a. 過河則划船。
b. 遇到妖怪則念經。
孫悟空。
a. 過河則飛。
b. 遇到妖怪則斬妖。
豬八戒。
a. 過河則游。
b. 遇到妖怪則呼救。
妖怪。
a. 遇到唐三藏則吃。
b. 遇到孫悟空則跑。
c. 遇到豬八戒則戲弄。
聰明的讀者，看出上面範例中的不同點了嗎？很明顯的，在傳統的方式裡雖然模組化可以將程式規劃的很清楚，但是免不了，每
一個模組都必須跟全域變數（或物件）糾纏在一起。這樣的結果，在團隊的開發中是非常不利的，因為任何人，任何模組的修正
都會影響到系統的正確性。而物件導向的模式則完全沒有這樣的問題。另外還有一個重點是在 OO 的思考模式裡，我們不但可以
順利切割整個應用程式的程式碼部分，就連程式中的邏輯部分，也一併切割的清清楚楚。這是一個在開發應用系統中，不容易出
錯的最主要關鍵。
討論到這裡，很多人都會問為什麼我們要採用物件導向程式設計（OOP）的方式來設計系統呢？其實原因無他，就是要減少系統
開發的時間以及出錯的機率。然而很遺憾的，在筆者接觸許多國內的案例中，雖然他們都是使用 Java、 Delphi、或者是 C++，
但是卻鮮少有人真正使用物件導向的思維來設計程式，更甚者，連基本模組化的工作，都做不好的，更大有人在，這是很令人痛
心的現象。因為這樣的結果，將導致國內的資訊市場中，充斥一些不健全的系統，而在劣幣驅逐良幣的情況下，國內將根本無法
擺脫軟體代工的命運。而所謂的資訊人，或許 說是有機會看到這篇文章的一群人而言，也會因為環境的因素，逐漸演變成一頭受
過高等教育但是只會拉磨的驢子而已。筆者在此並無意自抬身價，只是想藉由本文傳達一個訊息，那就是，其實我們還有更好的
選擇，可以讓我們的未來更加美好而已。
註 1：『記憶金庫』是一種開啟保險庫的遊戲，由旁人隨機唸出一堆密碼，然後再測試玩者能記憶多少個密碼的遊戲。
....
以下從裡面截取一些文章內容出來...
....
從上面的推演結果，相信讀者已經認可筆者的假設是可以獲得成立的，也就是說 VB 是支援 OO 的程式語言。嗯！這樣的說法相
當弔詭，而且在理論基礎上也有些牽強，不過本文撰寫的目的，不是要賣弄詭辯之術，而是要藉此機會向各位讀者說明，其實物
件導向程式設計是一種『設計的方法』、一種『思考模式』而不是一種『定理』。
....
從上面的範例中，相信聰明的讀者已經感受到同樣的程式，不同寫法之間的差異了。不過這些差異雖然對於使用者而言，是完全
感受不到它們之間的不同所在。對於毛主席而言，不管白貓或者是黑貓，也是只要會抓老鼠的貓，就是好貓，但是對於程式員在
作法上，差別影響就很大了。因為一支有條不紊的程式，總是比較容易維護。當然，對此有些人可能會不服氣，並且強調這是個
人程式撰寫的風格問題，但是筆者要強調的是，撰寫程式原本就是希望要迅速有效的為客戶解決問題，而不是在玩『記憶金庫』
（註 1）這樣的遊戲，當然更重要的是，程式要讓別人看的懂，這樣才可以提升軟體的價值，而使用 OO，也正是它提供方法來
達成這樣的目的。所以討論到這裡，我們可以回應本文之初所描述的那兩件事情，那就是：雖然 VB 普遍不被人認為是屬於OO
的程式語言，但是事實上，使用 VB，我們還是可以很 OO 的；同理，既使我們用的是 OO 的程式語言，例如 C++、 Java 等
程式語言，一樣可以寫出很不 OO 的系統出來。其中的關鍵，就是程式員是否真的具有 OO 的概念。
....
記得筆者之前所說的物件導向程式設計，是一種設計的方法，一種思考的模式嗎？剛剛筆者的演繹，只是示範了物件導向的設計
方法，而物件導向的思考的模式，則又是怎樣的一回事呢？我們以一個範例來說明：
現在我們預備撰寫一部西遊記的遊戲，其中的角色包括唐三藏、孫悟空、豬八戒以及妖怪等。然後在遊戲之中會遇到過河，以及
遇到妖怪等事件，在傳統的思考模式之中，系統通常會用切割成下面的樣子。
西遊記主程式。
過河。
遇到妖怪。
妖怪遇到三藏師徒。
其中過河部分會包括三個步驟：
如果唐三藏過河則划船。
如果孫悟空過河則用飛的。
如果豬八戒過河則用游的。
而三藏師徒遇到妖怪也會分成三個步驟：
如果唐三藏遇到妖怪則念經。
如果孫悟空遇到妖怪則斬妖。
如果豬八戒遇到妖怪則大喊救命。
而妖怪遇到三藏師徒也會分成三個步驟：
如果是唐三藏則吃掉。
如果是孫悟空則逃跑。
如果是豬八戒則戲弄他。
然而在物件導向的思考模式下，系統通常會用切割成下面的樣子。
系統主程式。
唐三藏。
a. 過河則划船。
b. 遇到妖怪則念經。
孫悟空。
a. 過河則飛。
b. 遇到妖怪則斬妖。
豬八戒。
a. 過河則游。
b. 遇到妖怪則呼救。
妖怪。
a. 遇到唐三藏則吃。
b. 遇到孫悟空則跑。
c. 遇到豬八戒則戲弄。
聰明的讀者，看出上面範例中的不同點了嗎？很明顯的，在傳統的方式裡雖然模組化可以將程式規劃的很清楚，但是免不了，每
一個模組都必須跟全域變數（或物件）糾纏在一起。這樣的結果，在團隊的開發中是非常不利的，因為任何人，任何模組的修正
都會影響到系統的正確性。而物件導向的模式則完全沒有這樣的問題。另外還有一個重點是在 OO 的思考模式裡，我們不但可以
順利切割整個應用程式的程式碼部分，就連程式中的邏輯部分，也一併切割的清清楚楚。這是一個在開發應用系統中，不容易出
錯的最主要關鍵。
討論到這裡，很多人都會問為什麼我們要採用物件導向程式設計（OOP）的方式來設計系統呢？其實原因無他，就是要減少系統
開發的時間以及出錯的機率。然而很遺憾的，在筆者接觸許多國內的案例中，雖然他們都是使用 Java、 Delphi、或者是 C++，
但是卻鮮少有人真正使用物件導向的思維來設計程式，更甚者，連基本模組化的工作，都做不好的，更大有人在，這是很令人痛
心的現象。因為這樣的結果，將導致國內的資訊市場中，充斥一些不健全的系統，而在劣幣驅逐良幣的情況下，國內將根本無法
擺脫軟體代工的命運。而所謂的資訊人，或許 說是有機會看到這篇文章的一群人而言，也會因為環境的因素，逐漸演變成一頭受
過高等教育但是只會拉磨的驢子而已。筆者在此並無意自抬身價，只是想藉由本文傳達一個訊息，那就是，其實我們還有更好的
選擇，可以讓我們的未來更加美好而已。
註 1：『記憶金庫』是一種開啟保險庫的遊戲，由旁人隨機唸出一堆密碼，然後再測試玩者能記憶多少個密碼的遊戲。
....
全站熱搜
留言列表
阿呆的生活點滴 (6)