好吧，标题可能听起来有点模糊，但我真的想不出更清楚的东西。
我最近处于需要Point课程的位置，只有两个属性，X和Y以及ctor Point(int x, int y)。没有什么花哨。现在这个东西已经存在于.NET中了，但这是在一个库中处理地图上的某些对象并将System.Drawing拖入这个只是觉得......错误的某种方式。即使System.Drawing.Point完全符合我的需求，我现在又在该项目中创建了该结构。
现在我想知道这是否是正确或明智的事情。如果我没记错的话，System.Drawing.Point也会提到那个集会。将System.Drawing中的内容放入完全非绘图相关的上下文中有点奇怪。
思考？如果它不暗示对另一个组件的引用怎么办？
答案 0 :(得分：6)
到目前为止，我不同意其他答案并说它确实很重要。 Point示例是一个简单的示例，但通常在上下文中使用它未设计的类可能会产生不良影响。
可能仅针对特定用例实施了一个类，例如不支持线程安全，需要在框架内使用或暴露代码中不需要的功能。
当部署更新版本的程序集时，它可能会特别导致问题，它不再与您使用它的方式兼容，或者较新版本带来了您不希望拥有的其他成员和依赖项。你的代码。
答案 1 :(得分：3)
命名空间的上下文是接近类的精确功能的基础;从一个命名空间到另一个命名空间，Connection类将成为一个非常不同的野兽。 Web.Cache类是否适合在其他应用程序中进行缓存，或者它是否基本依赖于Web基础结构？
MSDN描述System.Drawing.Point结构如下：
“表示一对有序的整数x和y坐标，用于定义二维平面中的点。”
通过这样的一般描述，可以认为这种结构只是偶然地与绘图有关，并且真正属于更基本的命名空间。
但是，它确实存在于System.Drawing中，其含义是它代表了二维绘图空间中的一个点。因此，将其用于绘图以外的目的是对课程的误用;它可能会满足您的需求，但它并未用于其原始目的。
答案 2 :(得分：1)
我不会说你所做的是错的，但是命名空间实际上只是一个声明的容器，其中每个名称都是唯一的，命名空间名称确实提供了一些上下文来帮助你找到适合你需要的功能但是不要如果物体是理想的那么它是理想的，那么就不会对你的用途感到不适应。除了using语句之外，您可能永远不会再次主动引用命名空间。
答案 3 :(得分：1)
如果你对这一点的目的与绘图无关，我认为你做对了。在代码中使用System.Drawing.Point完全没有任何绘图相关可能会使人们误以为它被用于某些绘图功能。
答案 4 :(得分：1)
我最近处于类似情况。不需要Point类，但我会以此为例。
我创建了自己的Point类，因为当我需要双打时，System.Drawing.Point使用整数。我后来意识到这是一个好主意，即使我只需要整数，因为我可以根据需要扩展类，并添加方法，接口和属性等。而我不可能我应该使用系统.Drawing.Point。
原则是你不应该在你的程序中复制知识，但在某些情况下，例如这个，它是无法避免的。
至于暗示对另一个程序集的引用，你可以这样做：
using Point = System.Drawing.Point; // or whatever your namespace is called
答案 5 :(得分：0)
我刚刚使用了System.Drawing.Point。为什么重新创造已经存在的东西？如果提供您需要的功能，谁会关心命名空间的名称。只是我的2美分......
答案 6 :(得分：0)
如果您没有导入任何“行李”（比如必须初始化您不使用的东西），那么这正是您所需要的，我会选择现有代码。重新创建现有代码毫无意义。您也可能会在以后发现执行所需功能并期望特定类的功能。
尽管如此，我仍然可以认为在你的代码中有一个“外星人”对象很奇怪。解决这个问题的一种方法是用你自己的观点对它进行子类化。如果您没有更改子类中的任何内容，那看起来有点奇怪，但这只在该类的源代码中可见，并且在您使用它的地方，它始终被命名。一旦你发现自己在自定义Point中添加功能，它就会开始看起来很聪明。
答案 7 :(得分：0)
我很担心从命名空间中引入一些东西，因为它在功能和概念上（如何在文档中描述）符合目标。
我可能会毫不犹豫地带来一个新的集会。在这种情况下，Point是如此快速地滚动自己的事实，我可能会认为这样做的麻烦少于向我正在编写的程序集中添加另一个依赖项的麻烦。
否则，只要我没有将它用作Key（GetHashCode impl。就其碰撞的方式而言并不是很好，例如{0,1}，{1,0}，{ 2,3}和{3,2}，如果你有很多低值或矩形分布点）我会用它。