感谢大家热烈讨论，看到不少网友对 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的写法