前置技能 第零式 - 物件、第一式 - 封裝、第二式 - 繼承
假設有個怪需求 「讓某種動物叫 回傳叫聲」
不知物件導向為何物的人可能這樣寫
這樣能不能跑呢？當然能 而且沒有錯誤
但是顯而易見 這種寫法隱藏著災難性的悲劇
因為客戶都很婊善變 他可能還養了獨角獸掐里 跟 海綿寶寶
這下switch不完了 而且蠢一點的傢伙還會打錯字 case 個 "掐裡" 之類的 然後 Bug 就像螢火蟲之墓 那樣的悲催
試試這個
WTF...這太神奇了 那陀像屎的 switch 跟他說 估掰
而且傳入參數從原本的 object 變成了 抽象型別 Animal 呼叫 Barking 不再需要轉型
實作 Barking 的細節 則被放在 繼承 Animal 的子類之中
在 LetAnimalBarking 方法中 不必去管這些細節 即是日後他要養火星金星人 這段程式都不需要被修改
我很喜歡用貓狗這個古典說詞做說明 因為很好懂
但是我不喜歡用它來做舉例 因為TMD 誰也不會寫個 貓模組 狗模組 還是只有我沒寫過這種模組?
這個就灑狗血的常見
一些龜毛客戶 要求 每筆紀錄 都要有 建立時間跟人員 修改時亦同
這裡有三張相似的 entity class
表單
帳單
案件
因為欄位各異 所以無可避免的 使用時得分別實作 新增 修改
這裡我只寫了其中一個 我想也沒人想看全部 ~.~
但是如同之前的貓狗怪叫 這樣也隱藏著災難性的悲劇
因為 紀錄 成員ID 跟 時間 的部分 一直在重複
如果類似的表有 N 多張 然後某天 PM 拍拍 SA 肩膀 SA 再拍拍你 跟你說
我們 MemberID 不再記錄在 Session 裡面了 要改
你會笑笑的說 好呀 沒問題
但是 SA 走了之後 你會這樣
因為這 N 多張的表 並不是 全都是你一個人寫的 你知道了 有些人總是 「比較天才」 你很難理解天才寫法
然後你的桌子就有點可憐
你開始向上帝懺會 當初沒有好好上課聽老師的話 學好多型的話 就能避開這次 災難性的悲劇
一個 風騷的 abstract 類
entity class 瘦身了!
新增 修改 的時候 不必考慮 如何紀錄 成員ID 跟 時間 的細節
哪天真的萬不得已 有個特例中的特例 不能用 之前的 LogOnCreate() LogOnEdit() 方法 還能自定義新類 覆寫該方法
這下你可以露出燦爛的微笑 因為你跟老闆說 改掉用 Session 記錄成員 要一周
但是其實你只改了 abstract 類 但這只會是個秘密
