市面上很多文章、影片分享了物件導向要如何應用。 卻很少人分享 這些概念是為了解決什麼問題 ，所以很多人就算學完了物件導向的概念，卻依舊沒有把它應用在手上的專案。 因此這個系列文中，筆者會先分享「直線思考下」我們會設計出怎樣糟糕的程式；接著再來討論如何應用物件導向的概念對程式做 Refactoring，提升程式未來的擴充性、維護性。 一、二、三、四、五、大綱 設計考卷 如果考卷的 Class 也被其他工程師使用 我們希望在「設定答案」時通知其他老師 老闆...我改不動了，打算用封裝進行重構 所以「封裝(Encapsulation)」這個概念幫我們解決了什麼問題？ 假使我們今天要製作一個線上考試的系統，相信「考卷」是考試的必要元素之一，今天我們就用它來舉例，說明「封裝」的重要性。 這邊我們先簡單定義「考卷（ExaminationPaper）」該有的屬性，像是「試卷名稱（name）、題目（questions）、答案（answers）」。 如果我們想要使用裡面的屬性，只要透過 new 將它實體化，接著用「.」就能夠存取使用，像是下面的範例中我們新增了一份「數學」考卷。 上面直接給考卷「試卷名稱、題目、解答」的方式看起來是不是很清爽？ 但如果今天這個系統除了你之外，還有其他的工程師也使用了這個考卷的 Class，在其他檔案去新增諸如「英文、國文、歷史...」的考卷，你覺得未來可能會發生什麼問題呢？ 今天設想一個情境，老師可能在出完考卷後發現提供的答案寫錯了，因此需要修改試卷答案；而校方為了確保試卷答案的正確性，希望系統可以在「設定答案」時發信通知其他老師，讓大家確認答案是否正確。 好的，此時身為工程師的你會怎麼做？ 去搜尋所有「examinationPaper.answers」的程式，然後在後面加上「sendEmail」的函式嗎？ 如果你真的採用上面的做法，假使這個試卷的 Class 被引用 100 次，那就需要在那 100 個地方新增「sendEmail」的函式；這個做法不但會增加日後程式維護的困難度，要是不久後校方要求「設定答案時，需要先經過審核」，那你就會改到想死吧？ 系統在設計時，就需要考慮到未來的擴充性；否則在需求變更時會死得很慘。 過去我們把「name、questions、answers」都設定為 public 可以直接存取，但就如同上面的範例，正因為可以「直接存取」而導致未來程式擴充性的問題。 因此在重構上，我們將「name、questions、answers」改為 private，如果想要存取則要透過 Getters、Setters 的函式。 重構後，儘管我們 ExaminationPaper 的 Class 變得更長，但是日後有其他需求新增時，我們可以更靈活的變更，維護性、可讀性、擴充性都增加不少。 以今天重構後的 Class 舉例，如果日後使用到設定答案： examinationPaper.answers = [...]; 就會觸發到 sendEmail 的函式。 透過封裝，我們可以保護 Class 屬性，不讓人隨意修改。 資料讀取、變更，透過 Getters、Setters 統一處理。 因為把方法封裝，所以在需求變更時，只要修改一個地方，不需要在每個用到的地方都修改。 ▶︎ 1.