感谢大家热烈讨论，看到不少网友对 interface 的话题有兴趣， 另外开一篇，欢迎大家一起来讨论 : -- :

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 73.70.25.48 (美国) : ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1747295625.A.D41.html : 推 ikachann: 很多都这样 一开始能动最重要，真的有闲稳定下来後才是 05/15 22:20 : → ikachann: 重构的部分 05/15 22:20 专案开发节奏跟着商业需求走的，需要速度的时候先能动，但方向确立後，就真的需要 排时间做 refactor，清理成好维护的 code, 不然容易快速 launch，然後就快速坠落 refactor 的时候往往遇到一些 code 无法写 UT，这时候就是该导入 abstraction layer 的时候了。 : 推 ikachann: interface真的是说到点了，可能补习班教吧 一堆人都照着 05/15 22:22 : → ikachann: 一个service都做一个interface然後就只有自己实作 05/15 22:22 : → neo5277: interface 还是看语言跟框架用啊 05/15 22:42 : 推 stepnight: interface 跟 DDD 就是互相成就 05/15 23:5 : 推 shibin: 推，好奇问，那如果是为了 UT 而弄的 interface 呢? 05/16 14:3 : 推 attacksoil: 有时候写interface是怕把依赖方向搞烂 有建议吗 05/17 22:2 : 推 tsaigi: 但c#要mock的话不是一定要interface吗？ 不测试的话的确 05/21 11:0 : → tsaigi: 是不用interface啦 聊到这个，除了 interface 还有 oop 继承的问题，早年学 OOP 都是狂用继承 但帮 parent class 改变行为，所有 children 就强迫一起自动获得这个改变， 如果有部分 children 不需要这个行为，事情就会变得非常棘手。 这就是为什麽会有 SOLID principle 的 O, open-close principle parent class 要设计成好开放扩充 (open) 但 parent class 本身不能随便改(close) 但这实务上不好做到，所以现在越来越常见提倡少用继承，尤其不要为了 reuse 某个 class 的功能而继承他。如果 class A 需要 reuse class B 的功能，可以在 class A 的 data member 建立一个 B 物件，然後呼叫他就好，不需要继承整个 B 的全部行为跟 介面，就可以有效避免这问题。 这个就是 compoisition over inheritence， 透过组合多个物件来 reuse 他们的功能，而不是继承他们的 classes 来取得这些功能。 当这样做的时候，每个物件就可以只负责一件事情 (single responsibility)， 他们就会很单纯很好测试，然後组合这堆物件来合作完成一个大功能。 每个物件就可以有很简单的介面，这就是 SOLID 的 S, single responsibility 这样对 testability 也有帮助，但这样衍生的问题，就是物件会拆得很多很散， 把这些东西正确兜再一起很复杂，於是就需要写 factory 来建造这些物件， 或是借助 dependency injection 工具，使得 dependency 的管理变复杂。 物件之间要正确的互动也复杂，这个的经典案例就是 Windows 输入法框架 tsf 每个 interface 都只有一个功能，大多只有一个 method，结果就是写个输入法 API 文件一打开散成上百个 interfaces，没有足够的范例谁知道要从何看起? 这种时候就需要，提供一个简单易用的 wrapper，来把这堆复杂互动包起来， 提供简单 API 让常用场景方便使用，这就是 facade pattern。 解决一个问题，往往会制造另外一个问题，所以最後你逐渐就上了软体工程全餐 : 推 stepnight: interface 跟 DDD 就是互相成就 05/15 23:56 : 推 shibin: 推，好奇问，那如果是为了 UT 而弄的 interface 呢? 05/16 14:39 如果是为了让某些 dependency 在测试期间能替换，这是合理的做法。 最常见的场景之一，就是把 clock API 包进 abstract interface 里面，然後 code 需要时间就 call abstract interface，而不是直接呼叫 system call 这样在 UT 里面就可以替换成假的，inject 写好的固定时间进去，不然每次跑都不一样 另外一个例子就是你的程式呼叫某个系统 API，但 UT 的环境不允许呼叫，或是每次结果 是随机的，那我们就会用 interface 把它包起来，让 UT 时可以替换成不同实作 这确实是很合理而且常见的作法。但除了这些特殊状况，其他多半不是必要的 测试的时候还是 Prefer real object，使用真实物件如果适合，尽量用真的 使用 fake or stub 每次你改变行为，这些 fake/stub/mock 也要跟着连动，如果没有 一起改到，UT 就可能会坏掉或是得出错误的结果，使用过度会非常难维护 test double 使用的目的，主要是为了观察内部互动 (mock)，提供假的固定数值 (stub) 或是避免外部依赖，例如避免连真实 server，或是加速，例如避免大量 disk I/O， 换成用 in-memory cache 的实作来加速 UT，除了这些状况，大多都可用 real object : 推 attacksoil: 有时候写interface是怕把依赖方向搞烂 有建议吗 05/17 22:28 我想你在讲的是 inversion of control or dependency inversion，也就是 SOLID 的 D 他要解决的问题是物件间高度耦合，所以让大家都依赖高阶抽象 interface，不直接 呼叫低阶的实作细节，低阶的实作要呼叫其他物件，也透过高阶介面，所以称"反转" 大家都只依赖介面而非特定实作，就达成低度耦合。 (注: Inversion of control (dependency injection) 和 dependency inversion 是不 同的东西，但实际上几乎会一起用，因为所有呼叫都是 abstract interface 的话， 那使用的 code 大多不会负责建造这些物件，所以几乎必然会从外面 inject 进来) 这要解决的问题是耦合，但耦合不等於不好。当两个物件就只有一种实作，然後他们就 真的只能搭配一起用无法抽换，那耦合其实也没有问题，没必要硬要解耦。 等你需要抽换不同实作的时候，再来抽 interface 其实常常也没关系。 会有问题的是 share library，事後补抽 interface 会变动 ABI，造成 binary 版本 不相容，需要重新编译。这种情境 interface 一开始订好不要动就会比较好。 然後 interface 越小越好，每个都只做最少的事情，就不会动一个东西就要到处改 这样对测试维护都比较好，也就是 SOLID 的 I, interface segregation : 推 tsaigi: 但c#要mock的话不是一定要interface吗？ 不测试的话的确 05/21 11:00 : → tsaigi: 是不用interface啦 05/21 11:00 上面讨论过 UT 了 : 推 jennya: 热爱尝试当下流行的新工具新理论的工程师，常常也是团队主 05/22 01:58 : → jennya: 力，很难找到理由阻止他们尝试新事物 05/22 01:58 确实，就只能定期 review，定期 refactor 了。 对导入新事物保持开放心态，同时也对万一发现不合适随时 rollback 保持开放 勇於尝试，但也勇於承认错误，就会是个比较健康的文化。 讲半天架构，耦合，好玩的是，实务上最後决定系统架构的，往往是 Conway's law 你的组织架构长怎样，系统架构最後就会长成那样.... XDDDD 虽然现在 AI 当红，还是很高兴有人一起来讨论这些日薄西山的传统软体工程啦! (泪) -- Sent from PCMan on PCMan's PC --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 73.70.25.48 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1747904496.A.E67.html ※ 编辑: HZYSoft (104.135.204.212 美国), 05/23/2025 01:28:17