作者uranusjr (←這人是超級笨蛋)
看板C_Sharp
標題Re: [問題] 實作內容相同但很可能改變的function
時間Wed Aug 20 21:33:50 2014
※ 引述《BigLoser (大魯蛇)》之銘言：
1F：→ uranusjr: 請用繼承, 不要用 switch 08/20 16:28
: 原本想用繼承，可是這些計算公式，是只有當中有一些不同，
: 專屬部分在每個狀況會有不同，
: 可是現在就算我計算公式1和2當讓大家共用，
: 又遇到另一個問題，就是未來a的計算公式1可能會變的不同，
: 這樣共用的部分就不行了，等於要獨立抽出來，
: 這種情況又該如何呢?
2F：→ ssccg: 要不要合併不是只看實作內容，要看代表的邏輯和用途 08/20 20:31
3F：→ ssccg: 你的舉例來說，你後面的問題來了根本不是個問題 08/20 20:35
4F：→ ssccg: 作法改了當然就呼叫新的function，跟原本的關係在哪? 08/20 20:37
5F：→ BigLoser: 公式大部分是共用的 只有一小部分不同 08/20 21:06
6F：→ BigLoser: *相同 08/20 21:06
我覺得你已經在鑽牛角尖了
沒有人規定程式裡不能有同樣的東西
一般會建議把相同的地方 extract 出來, 是因為這些東西是共用的
當你需要修改共用邏輯時, 只要修改 extract 出來的部分即可
這樣可以降低維護成本, 以及避免修改時發生錯誤
如果別人（或未來的你）需要閱讀你的程式, 也可以讓他們比較方便
但是即使兩個東西長得一樣, 不代表它們的邏輯就是共用的
以你的狀況而言, 既然「未來a的計算公式1可能會變的不同」
那麼就代表 a 與 b 根本就不是同一個東西, 只是剛好都用了計算公式 1
所以要嘛你還是把計算公式 1 抽出, 然後當 a 未來改變時改使用其他公式實作
要嘛就是你一開始就根本不應該把 a 和 b 看成同一類東西
Method extraction 這件事情本身就是用來降低維護與程式閱讀成本
所以當你在思考要不要, 以及要怎麼做時, 就應該把這兩件事當成目標
如果一味遵從教條, 為 refactor 而 refactor, 這些準則就失去意義了
--
7F：→ GNUGCC:void main(void) 的寫法是可行的唷^^08/10 00:59
8F：→ GNUGCC:雖然這個寫法較傳統,但是語法與文法都正確哦^^08/10 02:16
9F：→ GNUGCC:目前我使用的 Visual C++ 都接受 void main(void) 與 08/10 20:18
10F：→ GNUGCC:int main(void),各位可以把 C++ 專案改成原生 C++ 類型來 08/10 20:19
11F：→ GNUGCC:用 void main(void) 來寫發現也可通過編譯. 08/10 20:21
12F：→ GNUGCC:這個就是 Visual C++ 的彈性.08/11 20:23
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.161.94.175
※ 文章網址: http://webptt.com/m.aspx?n=bbs/C_Sharp/M.1408541632.A.702.html
13F：推 BigLoser: 好的，先謝謝你的回應，我需要消化和思考一下 08/20 22:59
14F：推 BigLoser: 還在學習怎麼讓程式更物件導向，再謝謝妳一次 08/20 23:04