感謝大家熱烈討論，看到不少網友對 interface 的話題有興趣，
另外開一篇，歡迎大家一起來討論
:

C#來說虛擬類別出來然後可以有不同實作又可以再掛介面目前我是覺得我的場景還算滿夠用

有時候覺得OO搞那麼複雜 不如C語言至少所見即所得新人也能trace code

推 為了隔離第三方呼叫而弄的 interface 是可接受的其餘等不同實作開始浮現再來抽是說 C 也是會使用 function pointer 解耦

後來發現OO寫到後面太複雜了就往functional靠了

推這篇

推推 不過SOLID的DIP跟IoC的DI應該是不同的東西？

推分享~好專業

在這個AI產UT的時代 更不該隨意抽象發現有模組能共用再抽象出來就好了

樓上說的沒錯，dependency inversion & injection 不同但兩者實務上常並用，我寫清楚好了，感謝糾正搞清楚每個東西是解決什麼問題，就可以知道什麼時候要用但用了一個往往就製造另一個問題，最後就整個套餐集滿了最後就分開看都是 best practice，但全部組起來卻看不懂在大型專案有些複雜度有必要之惡，了解脈落有助於理解

Accidental Complexity,不意外。Uncle Bob的SOLID都是一看合理但實際行不通的觀念。當作理想可以，但實務是折磨自己。

推推

組合起來就看不懂，有機會是boundary切太大，有多個職責在裡面。工程師要直接面對程式碼，視角上難免見樹不見林常常遇到SA/PM開需求都不加思索，畫面上有甚麼就開甚麼需求任何複雜的商業邏輯，都被他們開得好像只要CRUD就能完成 XD

謝謝大大分享，我經驗不是很多，主要是寫獨立遊戲，現在用的很接近你的軟體工程全餐，但是我使用起來感覺很條理system+factory+facade組一個系統，寫完了丟namespace對項目整體複雜度下降真的很有幫助。沒用設計模式之前寫出來的東西對心智負擔很大用設計模式不算壞事吧？

現在我幾乎不寫單元測試而是直接寫整合測試把自己當使用者去測完整行為了，本地端直接docker compose啟Postgres Redis等實在很方便，早期docker還沒那麼成熟時只能靠h2假裝一下…

說這麼多，其實我只是想提倡徹底理解各種practice的優缺比起把書上的東西當成教條奉行，更重要的是理解其內涵了解他們解決的問題和侷限，使用上就會更彈性和得心應手就能吃軟工自助餐，想要什麼就夾什麼，知道自己在做什麼

不就是為了一定要用某個概念，有沒有多偉大不知道。但這個概念產後的副作用另一個概念/方法來補救。

到最後c++我還是用free function > class xd

推徹底理解各種practice的優缺

有時候人在江湖 身不由己。 每次上面老闆急著要東西要你最快速趕出來。什麼clean code，design的東西全丟在旁邊，老闆看到能跑就爽了之後想要跟上面要時間去整理一下code, 好以後擴張，上面就會一副不耐煩的表情說不用動之後需要擴張時上面的又會嫌說當初怎麼寫的那麼亂很難擴張

了解了 推推

然後技術債就是大家比偷渡，用三寸不爛之舌把一些有隱憂的部分想盡辦法偷渡進下一個專案的排程

我個人看不順眼的code重構也是包在自己的時間內重構也不是整個重寫，評估處理個大概能用就好

project重構本來就應該包，只是很多人不接受

就是過於複雜了 語言特性決定一切 只有麻煩的語言才講究這些東西 然後還有些人當成寶 包含框架都是 我很

超熊貓大大...好厲害...

還可以

推一個

像c++就用他的lib就好 沒事別在那邊定義class

那就是C的寫法