Re: [請益] 如何選擇適合的設計模式

[JohnRoyer (日落 Zero)]

我對看到的其中幾句話有一些其他想法和想補充的地方
和大家分享


※ 引述《strlen (strlen)》之銘言：
: .....
: ..... 非到必要時刻不要使用

不是只有 SOLID 原則、設計模式非必要時不要用到
我覺得包括 clean code 裡面提到的東西、重構
甚至到 Effective SQL、CI/CD、SRE 之類的東西也一樣

沒有需要用到
表示手上的工作可以用最簡單的方式解決掉

但這些東西之所以會被整理成冊、流傳多年，甚至有些還被喻為必讀聖經
就是因為這些東西都是在特定領域最常被使用來解決問題的方法、流程
而且想逃避不用還不一定逃得掉

最好的方法是邊做、邊學、邊討論






上面幾句話提到的東西其實不少
再加上自己前一段講的名詞加起來
這輩子要學到透徹、學到精通應該蠻難的 (我想自己是做不到)
但建議把這些專有名詞都看過、知道有這個東西
因為可以大幅降低溝通成本、避免討論上不小心造成的誤解

「覺得這邊做 method extraction 以後再來用類似觀察者模式下去調整，應該就
  可以解決 ......」

聽到「method extraction」和「觀察者模式」可能沒辦法理解流程、程式調整方式
但若有聽過、知道這些名詞的概要、特性
就可以很快的了解需要重構、並讓類別提供一些特定的 method 供使用



覺得也不是說業界沒在用、或是不重視
只是這些東西默默融入生活中
討論的時候不一定會以專有名詞的方式出現而已

「試試看走下路，然後在森林出口和草叢附近種香菇」








: 沒有所謂的正確的模式

書上整理出來發法、設計方式
大多是遇到問題比較通用的解決方法，或是可以參考的常見設計方式
我目前幾乎沒有遇到剛剛好可以一模一樣完全照著做就能解決問題的問題

就和人生一樣，多數的問題都沒有最佳解，只有可能的較佳解
但有件事情是肯定的：站在巨人的肩膀上能少走一些冤枉路
累積更多的經驗、了解更多人的思路和解決方案
可以讓你在決策時做出更適當的選擇




----
突然覺得好像不該選擇在半夜寫垃圾 QQ

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.35.45.14 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1636306063.A.154.html
推 pjwck: clean code 跟能不能簡單解決沒太大關係吧
推 MatTZerS: 回樓上 看完clean最痛苦的我 就是明明只是寫一個簡單的
→ MatTZerS: 資料夾文件整理的程式 一個寫在main就能完成的事 我卻
→ MatTZerS: 還要想怎麼抽出函式 怎麼命名...
推 strlen: clean講得東西其實要分兩種 一種是所有地方皆通用的建議
→ strlen: 一種是所謂的「招式」 通用建議就是好好命名 一個method只
→ strlen: 做一件事 這些不管你什麼寫法都應該最好要知道的東西
→ strlen: 另一個「招式」就是SOLID和設計模式 這個就是你不只要會用
→ strlen: 還要會「選擇對的時機用」 後者比前者更困難
→ jej: clean code參考而已吧 你看阿里巴巴的開發guidelines
→ jej: 有些根本就和clean code背道而馳
→ jej: 舉exception為例子 clean code認為拋exception讓接收錯誤
→ jej: 的處理器用多型處理
→ jej: 阿里巴巴卻是強調要精確的exception
→ jej: 再來說程式撰寫的顆粒度 clean code不會和你說那些物件有坑
→ jej: 阿里巴巴會明確敘述 例如SimpleDateFormat
→ jej: 多看看幾本書 每本互相參考才比較好吧
推 qscesz1456: 越簡單越好 ... 也不用假想太多未來的狀況 9成都不會
推 ZakuSIN: 看完clean跟怎麼寫應該是兩回事?  沒有一定要這麼做
→ ZakuSIN: 程式沒有唯一解  只有適合的解法
→ viper9709: 越簡單越好+1
→ strlen: 多型事實上就是屬於「招式」的那一邊 有時間多看當然是好
→ strlen: 事 看越多你越能斟酌你目前的現況使用這些工具
→ strlen: 我只是說clean code有一些基本不能再基本的東西 DRY之類的
→ strlen: 不管你是寫什麼毛都應該要注意