貨櫃裝載的程式資料結構蠻複雜的！每個貨物都有很多屬性，每個貨櫃也有很多屬性，上百的貨物要規劃分別裝載到多個貨櫃，可以想像資料處理過程中需要用到的各種陣列有多複雜！如果不是已有二十多年的深厚功力，年輕時的我來玩這個遊戲，腦袋一定會爆掉的！

這就是物件導向程式概念所以會出現的原因了！如果你直接用一個獨立陣列代表所有貨物的X座標，另一個獨立陣列管理所有貨物的Y座標，再來一個陣列表示所有貨物所在的貨櫃編號，還要一個是與否的陣列標示每一貨物是橫放或豎立等等，依此類推，就是所謂的結構化程式了！這些陣列會非常多，而且有相關性，每一次你移動一個貨物，就必須「同步」修改或確認好多個相關陣列的內容！寫程式時就會很難操控極易出錯了！

物件導向的做法就不會這樣，長寬高等屬性會封裝到「貨物」這種類別的內部，需要用到某物件的長寬高等屬性時才取出來用。以目前我做的貨櫃裝載來說，理論上應該將貨物與貨櫃視為兩種類別，需要時就產生實體物件。譬如一千多個貨物，幾十個貨櫃之類的。程式碼並不會減少，但是寫程式時的思考管理比較輕鬆。

但我一向不是這麼守規矩的！我覺得讓貨櫃保持「不是物件」，所有貨櫃的屬性還是用全域陣列管理比較方便做整體思考！所以之前的程式只算半套的物件導向，貨物是物件導向化了，但是貨櫃並沒有！這樣還是能寫出完整有效的程式邏輯而且速度很快。唯一的缺點只有我自己受苦，就是程式碼與陣列架構較多而雜！想要擴充功能或介面時就會比較辛苦。

既然如此，年後開工就開始嘗試改寫成比較完整的物件導向程式吧？花了一整天是改好了，但如上圖所示，上面是之前的半套物件導向版本的成績，下面是完整物件導向改版之後的成果！很顯然的執行速度慢了好多(1.23/0.74=1.7)！還好本來速度就極快了，對使用者來說沒甚麼差別！

但是這個實驗可以告訴我們：不要迷信甚麼東西比較「先進」就各方面都好？結構化程式其實是直來直往效率比較高的，如果堅持使用完整的物件導向架構，甚麼資料都要經過封裝再取用，還必須宣告建構獨立物件等等，事實上是比較耗時的！好處呢？是對於寫程式的人思考管理比較方便。

做個比喻：結構化程式好像是一人公司，雖然老闆每件事都會作，但是校長兼撞鐘當然很累！物件導向就像老闆請了多位員工分頭辦事，只需要指揮屬下工作，不必管理太多細節就輕鬆多了！但實際效率通常是比較差的！因為老闆會開公司表示每一項業務他都會也精！最理想的狀況是複製老闆分身到各個部門同步工作！因為想法一致也不需要常開會，這是所有老闆(包括我在內)的肖想啦！

總之，藉此經驗簡單透露一下物件導向與結構化程式的差異，也提醒大家不是新的一定都好，舊的技術就一定不堪使用？實際上還是要看你的需求！如果目標軟體執行速度必須盡量求快時，物件導向其實是「不好」的選擇！如果速度要求不高，資料結構複雜或常常需要更新維護的程式，當然就要盡量物件導向化了！