什么是fat接口？

Question

再见，我在电影业工作，模拟和应用工作室的特效。我可以问一下什么是胖界面，因为我在网上听到有人在说它吗？

编辑:这是Nicol Bolas说的here (我相信这是一个很好的指针)

Answer 1

fat接口-具有比逻辑上所需更多的成员函数和朋友的接口。TC++PL 24.4.3 source

Answer 2

非常简单的解释是here

胖接口方法:除了核心服务(作为瘦接口的一部分)之外，它还提供了一组丰富的服务，以满足客户端代码的常见需求。显然，使用这样的类，需要编写的客户端代码量更小。

什么时候我们应该使用fat接口？如果期望一个类具有很长的生命周期，或者如果期望一个类有许多客户端，那么它应该提供一个胖接口。

Answer 3

Maxim引用了Stroustrup的术语表：

fat接口-具有比逻辑上所需更多的成员函数和朋友的接口。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上调用)-那么您就有了一个fat接口。

"Uncle Bob"在Interface Segregation Principle (ISP) (避免胖接口的SOLID原则)的上下文中对它进行了不同的强调(粗体我的)：

解决了“胖”接口的缺点。具有“胖”接口的类是其接口不是内聚的类。换句话说，类的接口可以拆分成成员函数组。每个组服务于一组不同的客户端。因此，一些客户端使用一组成员函数，而另一些客户端使用其他组的。

这意味着你可以拥有虚拟函数，所有的派生类都实现了非noop行为，但如果通常任何使用该接口的给定客户端只对其一组函数感兴趣，则仍然认为该接口是“胖”的。例如:如果一个string类提供了regexp函数，而95%的客户端代码从未使用过其中的任何函数，特别是如果有5%的客户端代码不使用非regexp字符串函数，那么您可能应该将regexp功能与普通的文本字符串功能分开。但是，在这种情况下，组成两个组的成员函数功能有明显的区别，当您编写代码时，您将清楚地知道您是想要regexp功能还是普通的文本处理功能。对于实际的std::string类，尽管它有很多函数，但我认为没有明确的函数分组，在最初只需要使用insert/erase之后，演变成需要使用某些函数(例如begin/end)会很奇怪。我个人并不认为这个界面是“胖”的，尽管它很大。

当然，这样一个令人回味的术语会被其他人用来表示他们认为它应该是什么意思，所以毫不奇怪，网络上包含了更简单的大于必要的接口用法的例子，就像relaxxx的答案中的链接所证明的那样，但我怀疑在计算科学文献中，更多的人是在猜测一种含义，而不是“受过教育”……