為什麼要用 Object Oriented 來解構世界？
簡單來說，Object Oriented 為解決現在的問題外，還要預測未來，預判下一步怎樣走，作好準備。Object Oriented 以【作好準備】而生，先解構世界，把世界重新定義成 Object，為各種 Object 套上關係，用程式碼重現世界。
軟體工程 ( software engineer ) 中，可以用 UML ( Unified Modeling Language ) 視圖化說明及分析設計系統 ( Object-oriented analysis and design ( OOAD ) )。
在談 Object Oriented 之前，首先要預測會遇上什麼問題，然後可以用什麼概念解決問題，所以先離一下題，講解 Reusable 及 Maintainability 概念。
Reusable 與 Maintainability 概念
由於概念上的東西比較難理解，所以反過來，先舉例，從例子中抽取概念，然後解釋其奧妙之處。霎時間很難完全掌握，不過文本好處，就是可以反芻，當人生經歷增長後，回頭再看一次，把認知、想法、比喻及例子修改一下，或許都有新發現、新啟發。
Reusable
【不必重新發明輪子】這句話，很好用來解說可重用性 ( Reusable )。軟件開發中，發明了某些功能，Bug都被修正，沒有安全漏洞，一直運作良好，也沒有多少改進空間，功能已改至完美，還經得起時間考驗，沿用至今。
例子有什麼？網路安全類就是最佳例子 ( SHA 及 RSA 演算法等 ) ，不需要理解演算法公式，功能是如何被程式碼實作，只需要理解輸入什麼及輸出結果，可以把這種功能套用到各式各樣的軟件及服務當中。
假如軟件是台機械，那麼，功能就是一個完美部件。所謂的完美部件，是能夠把這個拆下或複製，安裝在另一個機械上。
====================================
配合【不必重新發明輪子】這句話，先定義機械是【車】，部件是【輪子】。造【新車】不需要所有部件都是新的，把【舊車】拆一拆，組一組，部件換一換，也能是【新車】，而且用習慣的部件，不必重新適應，用得更安心，不必費時重新打造，省下造新部件的時間及費用，集好用及實惠於一身。
 |
| 由 Tao280m - 自己的作品, 創用CC 姓名標示-相同方式分享 3.0, https://commons.wikimedia.org/w/index.php?curid=8094372 |
舊車【輪子】要定了，看環境及自身需要，選一下餘下的部件，例如︰
引擎還能接受，不換。
排氣喉太貴買不起，用舊的。
習慣的軚盤及坐椅，還是舊的用得最安心。
汽車電池用舊了，買新的。
為慶祝新車落地，改名為【Dream car】……
註︰可想像成前期送豆腐的 AE86
 |
| 由 英文Wikipedia的Blueck - 從en.wikipedia轉移到共享資源。, 公有領域, https://commons.wikimedia.org/w/index.php?curid=1476525 |
事隔五年，【Dream car】不再是夢想中的 Dream car，決定造【新車】︰
【輪子】用上五年磨損嚴重，該換了 (換輪胎)。
有更好的引擎，OK換上新車吧。
五年中，存了一點閒錢，排氣喉該換一換，做點新嘗試。
需求改變，現在不是代步用的車，而是賽車用的車，雖然習慣舊軚盤及坐椅，但漸漸覺得追不上對手，是時候造新的賽車軚盤及賽車椅。
車的性質由代步車，拆拆改改，變成了賽車，【Dream car 2.0】誔生。
註︰可想像成後期 Project D 的 AE86
N年後，生化科技、火箭技術、自動駕駛、電動車、擴增實境 ( Augmented Reality ) 時代降臨，是時候科幻一點，【偽超級阿斯拉達】好不好？
即使再科幻，車還是有【輪子】(我不會承認沒輪胎的車)，【輪子】還是圓的，尺寸改一改，配個【DG細胞】，輪胎自備修復功能。
引擎以前用氣油，現在用電，不換也不行。
引擎用電的，有需要排氣嗎？決定拆掉，把排氣喉的錢放在自動駕駛系統 (阿斯拉)。
自動駕駛，軚盤沒需要，有個煞車制就搞定了。(拆軚盤)
有推進器的車，未來賽車後面都黏著火箭 (加火箭推進器) ……【Dream car Evolution】。
N年不變的，只餘下車架及輪圈。
=================================
Maintainability
我也知道以上例子有點扯，不過人要有點夢想，才有前進方向，也為 Maintainability 概念墊路。
Reusable 與 Maintainability 關係密切，用以上例子解說，Reusable 可以簡單理解成【重用舊部件】。好了，問題出現，部件與部件之間如何接起來？當然不是用萬能膠黏起來，那些部件不是紙札品。
以車輪接上傳動系統為例，我們要用【螺絲】把它們接起來，又有問題了，【螺絲】有很多種，用那種【螺絲】？那種大小？那種長度？這個時候需要【標準 (standard)】，生產部件的廠商們，需要有共識，定義大家要用六角螺絲、直經 21mm、長度 35mm 之類。
不跟標準生產的部件，理所當然地接不上，接不上並不代表要買新的，可以用轉接器方法接上，假設這個轉接器沒有現成，要自制。本來不需要理解的結構，被迫理解，理解部件接位差異，只有理解是不夠，你需要創造轉接器，有一百間廠商，有一百種做法……是不是很煩？是不是很煩？是不是很煩？肯定煩惱到秃頭吧！
可維護性 ( Maintainability )，隨時代變化，requirement 改變，用最省錢省力省資源的方法達成目標。重用 ( reuse ) 就是最省錢省力省資源，不過在跟隨時代變化，因應需求改變這條件上，達不成目標。
之前，Reusable 可簡單理解成【重用舊部件】，是時候把定義進化一下，現在應理解成【重用有限度修改的舊部件】，使用共同標準 ( standard ) 是一種方法，模組化 ( modularize ) 是一種方法，把複雜度 ( complexity ) 降低是一種方法，並不是三選一或三選二，可全選，融合所有方法。
=================================
標準 ( standard )、模組化 ( modularize )、複雜度 ( complexity )
主角還是輪子，不過時代先倒退到中世紀。那時候的輪子是木制的，一整個就是全部，假如磨損了怎麼辦？整個換掉……會不會太浪費了？磨損的部份多數是與地面接觸的外圈，假如能替換外圈，不就可以重用中間的部份？
跳到19世紀，發明了車胎，現在的【輪子】可以拆分為【輪胎】及【輪圈】，磨損的輪胎可以替換掉，還可以因應需求，換上合適的輪胎 (雨天不易打滑的、泥雪地用、越野用等等)。
標準 ( standard )
輪胎商想造多大就多大，多小就多小，叫輪圈商怎造輪圈？共識及共同標準，之前就有提及過，有句話說得好——【不要在標準上競爭】。
模組化 ( modularize )
【輪胎】+【輪圈】= 【輪子】
把輪胎變成模組，組成雪泥用輪子、越野用輪子。這樣就能跟據需求改變，重用最多資源，減少開發時間，對應改變，在維護性上更進一步。
複雜度 ( complexity )
有點難解釋，不過用最後那個黑科技輪子作為解釋的話剛好。人工智能的生化輪子，能夠無視輪圈尺寸標準，可自動調整至適合輪圈大小，輪子還能變型，對應駕駛環境，自動生成適合胎紋及改變車胎大小，更備有自我修復，抵抗車胎磨損，可說是【無限度修改的部件】。
不過，有沒有想過，這輪胎出問題，怎麼辦？找誰做維修？假設全世界只有十個天才可以修理這種輪子，要維修的話，一定開天殺價吧？而且要看天才心情，做不做你生意。省錢省力省資源，只在沒出問題的時候，這種複雜度突破天際的輪子，根本不合成本效益，反而選擇複雜度低，誰都可以修理，五至十年後只能丟棄的輪子，或許更合算。
英文中有個有趣的比喻——【not rocket science】快去 Google 一下。
=======================================
在分析及設計系統上，沒有標準答案，可能這一刻覺得這設計非常完美，當見識及資歷都增長後，或許覺得這設計是一坨屎。
感覺設計走歪了，可以做重構 ( Code refactoring )，在 complexity、maintainability 及 requirement 上，作出平衡是很常見的事。所以不要太擔憂設計不良，本來 requirement 一直都在改變，新技術又不斷擁現，而且 OOAD 不是一學就會的技巧，都是靠磨練出來的匠人技藝。
寫程式碼時，不斷回顧過去，審視現在，預測未來，這篇文章會因為反覆閱讀而改變對各詞的認知。當有自己一套想法的時候，或許會覺得這是一篇誤人子弟的垃圾……
下一回【解構世界 ——功課篇】
