EIT造型技術思維(一)_繼承??抽象??_基底(父)類別並非抽象出來的

在 作者Fred Brooks所撰寫的
The Mythical Man-Month一書中
曾有提及到

"The complexity of software is an essential property, not an accidental one."

軟體複雜是與生俱來的性質

因此程式人員通常會希望愈簡單愈好
化繁為簡
通常面對複雜情況會傾向找到簡單或是邏輯一致的規則
才不會害怕


到底怎麼從複雜轉化成簡單?
通常會去關注變化和差異
將差異去除提取抽象的共同結構(留下萬變不離其宗的共通性過程就稱為抽象)

比方說:
三角形、正方形、長方形在這些具象中觀察變化
變化上就是面積、邊長、等等
那我們會提取出形狀的一個抽象結構
(從本質上來看這些都是形狀，形狀通常都會有面積、內角和等等屬性)

這是以往的思維但也就涉及到你必須找到
所有的具象，這就會導致不敏捷，因為需要找很久。

這裡舉生活化一點的例子
假設今天你面對的具象是
茶葉、水果、咖啡豆
請進行抽象
這時你會開始苦惱不像剛剛的形狀這麼理想這麼容易找到共通點

信用卡
MasterCard、Visa、........一堆具象要找到所有實在太耗時此外一些不同銀行變化
規則更複雜

或者抓一堆貓
每隻鬍鬚都不同這時你把鬍鬚去除
每隻尾巴也都不同乾脆也去除
.....其他又有不同的比如眼睛、鼻子、.....
因此我們得到
一個沒有尾巴、沒有鬍鬚、沒有眼睛、嘴巴的這個叫貓
確實得到簡單(不變的部分)但也傷害到其完整性


因此若要敏捷就不能在尋找不變!!!!!!

杯子並非從果汁、咖啡當中抽想出來的，但不論果汁跟咖啡都能裝進去
皮包也不是從一堆生活物品中抽象出來的不變部分


Essence 簡單一詞其實於東西方認知是有差異的
西方人認為簡單一詞是指不可或缺的
東方人則認為是永恆不變的本質或真理

一隻貓就必須要有尾巴、鬍鬚所以不能去除
那要如何達到簡單呢??
你不用刪除也不需要去剖析差異直接把一整隻貓裝進皮帶中
過去我們追求不變，追求不變作法則是將變化刪除，而非有效掌握變化。




上述提到的東西方觀點
其實只是不同視角、思維(一體兩面)
任何視角本身無對錯、更多視角才能讓設計更可靠。
比方汽車
我們會針對變化去做相應設計
有些是因地形而改變，比如:輪胎大小。
有些則因人而變，比如:方向盤大小、車子顏色。
到底我們要怎麼抽離變化呢?
其實我們一次只能從一個面向去下手
但當角度不同時抽象出來的結果就會不同


假設我們今天預計開發兩種軟體系統

智慧家庭系統(模組A):
需要執行到工廠作業站連網和溝通

智慧交通聯網系統(模組B):
同樣也牽涉到網路連線的功能


使用情境:
屋主透過家裡聲控方式對智慧家庭系統下達指令
接著傳輸給汽車上安裝的交通聯網系統進行相應互動



通常開發工程人員會先定義好
通訊協定規格(到底怎麼相互溝通)
到底要用WIFI、Bluetooth、ZigBee.....??
等一切定義好
在去對兩邊模組進行依序或同步開發

但通訊技術日新月異，試圖先制定好善變的功能區塊
其實於實務上效果是有侷限性的
中途可能甚至因為呼叫的API或是規格語法改變使你要去改變兩邊系統


此時我們可以對兩邊創造出基類將善變內容放入其中
將善變內容放入Base Class中!!!!!!!
這樣當通訊協定一改只需要去改Base Class內容
這樣也可以避免更動到原本在兩端已執行很穩定又悠久的程式區塊