Ciao，我在电影行业工作，负责模拟和应用工作室效果。请问一下什么是胖接口，我听到这里有人在网上说它？
编辑：这是 Nicol Bolas 所说的 here（我相信非常好的指针）
【问题讨论】：
标签： c++
fat interface - 一个具有比逻辑上需要的更多成员函数和朋友的接口。 TC++PL 24.4.3 source
【讨论】：
很简单的解释就是here:
胖接口方法[...]：除了核心服务（作为瘦接口的一部分）之外，它还提供了一组丰富的服务来满足客户代码的常见需求。显然，有了这些类，需要编写的客户端代码量就更少了。
什么时候应该使用胖接口？如果一个类预计有很长的生命周期，或者如果一个类预计有很多客户，那么它应该提供一个胖接口。
【讨论】：
Maxim 引用 Stroustrup 的词汇表：
fat interface - 一个具有比逻辑上需要的更多成员函数和朋友的接口。 TC++PL 24.4.3
Maxim 没有提供任何解释，而对这个问题的其他现有答案错误将上述解释 - 或者说没有 Stroustrup 引用该术语本身 - 意味着具有可以说是过多成员的接口。 不是。
实际上不是关于成员的数量，而是成员是否对所有实现都有意义 .
在 Stroustrup 的词汇表中并没有很清楚地表达出来的微妙方面，但至少在我拥有的 TC++PL 的旧版本中 - 很清楚该术语在文本中的使用位置。一旦理解了区别，词汇表条目显然与之一致，但是“比逻辑上需要的成员函数和朋友更多”是应该从每个实现的角度应用的测试一个逻辑接口。 （我的理解也是supported by Wikipedia，不管它值多少钱；-o。）
特别是当你有一个跨多个实现的接口时，并且某些接口操作只对某些实现有意义，那么你有一个胖接口，你可以在其中要求活动的实现做一些它没有希望的事情这样做，并且您必须通过一些“不支持”的发现或报告使界面复杂化，这很快就会增加更难编写可靠的客户端代码。
例如，如果您有一个Shape 基类和派生的Circle 和Square 类，并考虑添加一个double get_radius() const 成员：您可以这样做并拥有它throw 或返回一些标记值像 NaN 或 -1 如果在 Square 上调用 - 你会有一个胖接口。
"Uncle Bob" 在Interface Segregation Principle (ISP) 的背景下（SOLID 避免胖接口的原则）在下面（粗体我的）对它进行了不同的强调：
[ISP] 处理“胖”接口的缺点。具有“胖”接口的类是指其接口没有内聚性的类。换句话说，类的接口可以分解成多组成员函数。每个组都服务于不同的客户集。因此，一些客户端使用一组成员函数，而其他客户端使用其他组。
这意味着您可以拥有例如所有派生类都使用非 noop 行为实现的虚函数，但如果通常使用该接口的任何给定客户端只对它的一组函数感兴趣，则仍然认为接口“胖”。例如：如果一个字符串类提供了正则表达式函数，而 95% 的客户端代码从未使用过这些函数，特别是如果 5% 没有使用非正则表达式字符串函数，那么您可能应该将正则表达式分开来自普通文本字符串功能的功能。但在这种情况下，形成 2 个组的成员函数功能有明显的区别，当您编写代码时，您会清楚地知道您想要正则表达式功能还是普通的文本处理功能。对于实际的std::string 类，虽然它有很多功能，但我认为没有明确的功能分组，在这些功能之后发展需要使用某些功能（例如begin/end）会很奇怪最初只需要说insert/erase。我个人并不认为界面“胖”，即使它很大。
当然，其他人会选择这样一个令人回味的术语来表示他们认为应该表示的任何含义，因此网络包含简单的大于必要的界面使用示例也就不足为奇了，正如所证明的那样通过relaxxx的答案中的链接，但我怀疑更多的人猜测含义而不是“受过教育”关于计算机科学文献中的先前用法......
【讨论】：
具有比实际需要更多的方法或朋友的接口。
【讨论】：