範型定義

範型(paradigm)，即為典型範例 - 標準結構化程式設計比較異同的方式，可以想像成一種程式設計風格。常見的範型還有：函數式程式設計、指令式程式設計、程序式程式設計等等。

工程師最討厭的課題：『變動的需求』

相信有在寫程式的pg或碼農們(我就是其中一個= =)，最討厭的就是需求一直在變動，寫好的程式碼要一直修修改改，書中有提及：

許多bug都源於程式碼的修改

沒錯！當你想說程式碼改個小地方而已，卻沒想到其他地方也跟著報錯，接著就會越錯越多，一步錯步步錯，然後過了一小時後看到滿滿紅色蚯蚓的程式碼，(決定關掉專案先躺平再說…)，這種情況蠻常發生的，但我們又沒辦法有強而有力的說詞去說服主管或客戶，因為程式碼改了會報錯，所以這次的需求沒辦法達成唷(會被打XD)，所以我們必須要學會如何彈性的寫程式。

這裡先提及一個常見的術語，內聚性(cohesion) & 耦合性(coupling)：

• 內聚性指的是「一個副程式內部組成部分之間相互關聯的緊密程度」。

• 耦合性指的是「兩個副程式之間關聯的緊密程度」。

上面有說到程式碼修改後會像雪球滾下山，越滾越大的原因，就是因為低內聚與高耦合造成的！

物件導向的彈性

我們雖然無法預測到未來的需求會發生甚麼變化，但通常是可以預期到哪裡會發生改變。物件導向的最大優點之一，就是可以封裝這些變化區域，因此可以更容易將程式與變化產生的影響隔離開來。

貼切的例子：『學校上課』

假設你現在是講師，聽課的學生在課後要到其他教室去上別的課程，但他們並不知道下一堂聽課的地點，此時你的責任就是確保所有學生都能知道下一堂課要去哪裡上。

如果照結構化程式設計方式，可能會分成以下步驟：

1. 獲得學生名單。
2. 對於所有學生會做以下工作
   1. 找到他要聽的下一堂課。
   2. 找到該課的地點。
   3. 找到從你的教室到該地點的路線。
   4. 告訴學生該路線要怎麼走。

但如果換個思考方式，講師將從這間教室到所有的其他上課地點的路線都列出來，並且貼到教室佈告欄上，只要在下課時告訴學生們請自行到佈告欄查看你們如何到下堂課地點的路線，這樣就好了。

• 第一種方式是直接為每個人提供指示，需要密切關注大量的細節，如果你有一百位學生....(不敢想像)。
• 第二種方式，你只給了通用的提示，然後期待每個人會自己了解怎樣完成任務。

兩者之間最大的差距就是『責任的轉移』，如果以程式角度來看：

1. 學生對自己的行為負責，而不是由一個中央控制程式負責決定他們的行為(因此他們需要知道自己是甚麼類型的學生，這在下一篇的內容會提及)。
2. 中央控制程式不需知道學生從這個教室到那個教室需採取的任何特殊步驟。

(是不是有一種似曾相似的感覺，好像在C#中使用介面 Interface 去定義每個 Class 需要實作的方法)

軟體開發視角

最後提一下本書中介紹到 Martin Fowler 的三個不同視角

今天先寫到這裡，看完這個例子，是不是越來越有感覺，好像常常碰到呀，我們明天再繼續說下去~~