矩形::包含(点)或点::is_inside(矩形)
API 应该提供 Rect::contains(Point) 或 Point::is_inside(Rect) 还是两者都提供？ 或 Math::contains(Point, Rect) 因为它是对称的？
同样的 Q 也适用于 LineSegment::contains(Point)、Rect::filled_contains(Circle) 等。
Should an API provide Rect::contains(Point) or Point::is_inside(Rect) or both?
or Math::contains(Point, Rect) cause it's symmetric?
The same Q goes for LineSegment::contains(Point), Rect::fully_contains(Circle) etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Rect::contains(Point)最有意义，因为它是一个构建块。 另一个并不是真正必要的，因为您希望每个特定形状都能实现该操作，而Point则不必知道每个可能的形状。 同样的答案也适用于 LineSegment。关于
Circle和Rect之间的关系，使用大多数面向对象的框架会更加棘手，并且没有任何明确的答案。 一些其他风格的面向对象（例如 CLOS）通过使用通用函数和方法来做到这一点，这使其成为一个毫无疑问的问题。Rect::contains(Point)makes most sense as it is a building block. The other is not really necessary as you would expect every specific shape to implement the operation, whereas thePointdoes not have to know about every possible shape. The same answer goes forLineSegment.Regarding the relation between
CircleandRectit is more tricky using most object oriented frameworks and does not have any definitive answer. Some other style of object oriented like CLOS do it by using generic functions and methods making it a non question.完全取决于是什么使你的程序的表达更清晰，更符合你想要解决的问题。 所以在某种程度上，以上所有内容在不同的情况下都应该没问题。
不过，一般来说，我稍微倾向于
Rect::contains(Point)而不是Point::Is_inside(Rect)。 这是因为我认为Point类应该被所有类型的类（如“Circle”、“Hexagon”等）使用，因此应该非常基本，并且只包含最小的接口。Math::contains(Rect, Point)将是我的第二选择。 如果我想让我的 Rectangle 类保持非常原始并且不向其中添加太多“方便”功能，我会使用这种方法。要记住的重要一点是，不要将类的设计视为一成不变的。 只需继续选择现在看起来最好的设计即可。 每当您的需求发生变化时，您都可以而且应该更改它。 这就是所谓的重构。
Depends entirely on what makes the expression of your program cleaner, more aligned with the problem you're trying to solve. So to some extent, all of the above should be fine in different contexts.
However, generally speaking, I am slightly tilted in the favour of
Rect::contains(Point)rather thanPoint::Is_inside(Rect). That's because I think thePointclass, since it would be used by all kinds of classes (like a 'Circle', 'Hexagon' etc.) should be very basic and contain only the minimum interface.Math::contains(Rect, Point)would be my second choice. I would use this approach, if I wanted to keep my Rectangle class very primitive and not add too much "convenience" functions to it.An important thing to remember is, don't consider the design of your classes as written in stone. Just go ahead and pick the design that looks best now. Whenever your needs change, you can and you should alter it. This is what is called refactoring.
我同意 Frederick 的 Math::contains 方法，尽管我认为最大的缺点是开发人员在查找方法时失去了 IntelliSense 的可发现性。 这是我对 Boost 和 STL 的不满之一。
Rect::contains 最终出错的一个例子是 iPhone SDK 绘制字符串的方法，该方法基本上是 String::drawInRect。
I'm with Frederick on the Math::contains approach, although the biggest drawback in my opinion is that the developer loses the discoverability of IntelliSense in finding the method. That's one of my beefs with Boost and STL.
An example of where Rect::contains eventually goes wrong is the iPhone SDK's method of drawing strings, which is basically String::drawInRect.
这取决于实现，但像 Federick 一样，我也倾向于选择 Math::contains(Rect,Point)，而不是 Rect::contains(Point)。 原因是后者导致了一个对象层次结构，其中包括作为虚拟的 contains 成员函数，该函数在类之间被重写。 当您处理大量矩形和类似图元时，这可能会产生潜在的巨大开销。
It depends on the implementation, but like Federick I would also tend to go for Math::contains(Rect,Point), over Rect::contains(Point). The reason for this is that the latter leads to an object hierarchy which includes the contains member function as a virtual, which gets overridden from class to class. This can have a potentially significant overhead where you are dealing with very large numbers of rectangles and similar primitives.