什么是胖接口？
你好，我在电影行业工作，模拟和应用工作室效果。我可以问一下什么是胖接口吗？我听到网上有人说它是什么？
编辑：这是 Nicol Bolas 所说的这里（我相信非常好的指针）
Ciao, I work in movie industry to simulate and apply studio effects. May I ask what is a fat interface as I hear someone online around here stating it ?
Edit: It is here said by Nicol Bolas (very good pointer I believe)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
非常简单的解释是此处：
very simple explanation is here:
马克西姆引用了斯特鲁斯特鲁普的术语：
Maxim 没有提供任何解释，并且该问题的其他现有答案错误解释了上述内容 - 或者没有 Stroustrup 引用该术语本身 - 意味着具有可以说过多数量的接口成员。 不是。
实际上与成员数量无关，而是成员是否对所有实现都有意义< /strong>。
这个微妙的方面在 Stroustrup 的术语表中并没有表现得很清楚，但至少在我的旧版本 TC++PL 中 - 很清楚在文本中使用该术语的位置。一旦您理解了差异，术语表条目显然与之一致，但是“成员函数和朋友多于逻辑上必要的数量”是一个测试，应该从每个实现的角度进行应用一个逻辑接口。 （我的理解也受维基百科支持，无论什么价值；-o。）
特别是当你有一个跨越多个实现的接口，并且某些接口操作仅对某些实现有意义，那么您就有一个胖接口，您可以在其中要求活动实现做一些它不希望做的事情，并且您必须通过一些“不支持”的发现或报告使界面变得复杂，这很快就会使编写可靠的客户端代码变得更加困难强>。
例如，如果您有一个
Shape基类和派生的Circle和Square类，并考虑添加一个double get_radius() const成员：如果在上调用，您可以这样做并让它抛出或返回一些标记值，例如NaN或-1代码>正方形 - 你会然后有一个胖接口。"Uncle Bob" 在上下文中对它进行了不同的强调（粗体是我的） 接口隔离原则 (ISP)（a SOLID 原则指出要避免胖接口）：
这意味着您可以拥有所有派生类都以非 noop 行为实现的虚拟函数，但如果通常使用该接口的任何给定客户端仅对其一组函数感兴趣，则仍将接口视为“胖”。例如：如果一个字符串类提供了正则表达式函数，并且 95% 的客户端代码从未使用过其中任何一个，特别是如果 5% 的客户端代码不倾向于使用非正则表达式字符串函数，那么您可能应该将正则表达式分开功能与普通文本字符串功能不同。但在这种情况下，形成 2 组的成员函数功能有明显的区别，当您编写代码时，您会清楚地知道您需要正则表达式功能还是普通的文本处理功能。对于实际的 std::string 类，尽管它有很多函数，但我认为没有明确的函数分组，如果需要使用某些函数（例如 < code>begin/
end），最初只需要说insert/erase。我个人并不认为界面“胖”，尽管它很大。当然，这样一个令人回味的术语会被其他人用来表示他们认为应该表示的任何含义，因此网络包含更简单的大于必要的界面用法的示例也就不足为奇了，如链接所示在relaxxx的回答中，但我怀疑更多的人猜测其含义，而不是“受过教育”关于计算科学文献中先前用法的人......
Maxim quotes Stroustrup's glossary:
Maxim provides no explanation, and other existing answers to this question misinterpret the above - or sans the Stroustrup quote the term itself - as meaning an interface with an arguably excessive number of members. It's not.
It's actually not about the number of members, but whether the members make sense for all the implementations.
That subtle aspect that doesn't come through very clearly in Stroustrup's glossary, but at least in the old version of TC++PL I have - is clear where the term's used in the text. Once you understand the difference, the glossary entry is clearly consistent with it, but "more member functions and friends than are logically necessary" is a test that should be applied from the perspective of each of the implementations of a logical interface. (My understanding's also supported by Wikipedia, for whatever that's worth ;-o.)
Specifically when you have an interface over several implementations, and some of the interface actions are only meaningful for some of the implementations, then you have a fat interface in which you can ask the active implementation to do something that it has no hope of doing, and you have to complicate the interface with some "not supported" discovery or reporting, which soon adds up to make it harder to write reliable client code.
For example, if you have a
Shapebase class and derivedCircleandSquareclasses, and contemplate adding adouble get_radius() constmember: you could do so and have itthrowor return some sentinel value likeNaNor-1if called on aSquare- you'd then have a fat interface."Uncle Bob" puts a different emphasis on it below (boldfacing mine) in the context of the Interface Segregation Principle (ISP) (a SOLID principle that says to avoid fat interfaces):
This implies you could have e.g. virtual functions that all derived classes do implementation with non-noop behaviours, but still consider the interface "fat" if typically any given client using that interface would only be interested in one group of its functions. For example: if a string class provided regexp functions and 95% of client code never used any of those, and especially if the 5% that did didn't tend to use the non-regexp string functions, then you should probably separate the regexp functionality from the normal textual string functionality. In that case though, there's a clear distinction in member function functionality that forms 2 groups, and when you were writing your code you'd have a clear idea whether you wanted regexp functionality or normal text-handling functionality. With the actual
std::stringclass, although it has a lot of functions I'd argue that there's no clear grouping of functions where it would be weird to evolve a need to use some functions (e.g.begin/end) after having initially needed only sayinsert/erase. I don't personally consider the interface "fat", even though it's huge.Of course, such an evocative term will have been picked up by other people to mean whatever they think it should mean, so it's no surprise that the web contains examples of the simpler larger-than-necessary-interface usage, as evidenced by the link in relaxxx's answer, but I suspect that's more people guessing at a meaning than "educated" about prior usage in Computing Science literature....
具有比实际需要更多的方法或朋友的接口。
An interface with more methods or friends than is really necessary.