2010-08-18 25 views
8

好吧,标题可能听起来有点模糊,但我真的想不到在这里更清楚的事情。命名空间隐含的上下文有多重要?

我最近处于需要Point班的位置,只需要两个属性,XY和ctor Point(int x, int y)。没有什么花哨。现在这个东西已经存在于.NET中,但是这是在一个处理地图上的某些对象的库中,并且将System.Drawing拖入到这个中,只是觉得......错误。尽管System.Drawing.Point适合我完美需要的东西,但我现在再次在该项目中创建了该结构。

现在我想知道这是对的还是明智的做法。如果我没有记错的话,System.Drawing.Point也会提及这个程序集。将System.Drawing中的东西放入完全不与绘图相关的上下文中有点奇怪。

想法?如果它不意味着提到另一个程序集呢?

+0

对我来说,这是明智的做法。 – VinayC 2010-08-18 11:56:41

回答

3

命名空间的上下文是接近一个类的精确函数的基础;一个Connection类将从一个命名空间到另一个命名空间成为一个非常不同的野兽。 Web.Cache类是否适用于其他应用程序中的缓存,还是它对Web基础结构有根本的依赖关系?

MSDN描述System.Drawing.Point结构如下:

“表示有序对整数x和y坐标,其限定在二维平面上的点的”。

有了这样的一般描述,可以认为这个结构只是偶然地与绘图相关,并且确实属于更基本的命名空间。

但是,因为它确实生活在System.Drawing中,所以暗示它代表了2维绘图空间内的一个点。因此,将其用于绘图以外的目的是对班级的误用;它可能会满足您的需求,但不会用于最初的目的。

1

我不会说你做了什么是错误的,但是一个名称空间实际上只是一个声明的容器,其中每个名称都是唯一的,名称空间名称确实提供了一些上下文来帮助您找到适合您需要的函数,但是如果对象是理想的,那么不要挂在不适合你的用途的环境上。除了使用语句之外,您可能再也不会主动引用该命名空间。

+0

我从2降低到1,以帮助减轻答案的影响,并希望提供更多的重点更高的评分答案,因为这个Q/A非常重要。特别是因为这是一个非常普遍的问题。在一个具体的例子中,根据需要考虑的依赖关系的重要性和其他因素,它可能确实是一个非问题,正如你所暗示的那样。但是,尽管每个开发人员都应该以“不要重新发明轮子”为理念,但我认为这是一种VB风格的思维方式,不恰当地使用名称空间,如果可能的话应该避免。 – Suamere 2014-05-27 13:45:26

+0

@Suamere虽然你当然有权发表你的意见,但这只是你的意见,除非你认为答案其实是不正确的,否则向下投票以“提供平衡”是非常奇怪的行为。当然,你需要对每一个不符合你“正确”观点的答案进行投票。 – Lazarus 2014-06-13 13:27:31

+0

是的。我在我看来赞成所有我不同意的答案,并且赞成我认为我同意的所有答案。好的观察。我只是碰巧评论你的,因为你有一个很好的答案,但这不是对这个问题的正确答案。 – Suamere 2014-06-14 04:24:39

0

我会刚刚使用System.Drawing.Point。为什么重新创建已经存在的东西?如果提供了所需的功能,谁会关心名称空间的调用方式。只是我的2美分...

0

如果你没有导入任何“行李”(比如必须初始化你不使用的东西),所以它正是你所需要的,我会去寻找现有的代码。重新创建现有代码没有意义。机会还在于你可能会发现稍后执行你需要的功能并期待那个特定类的功能。

尽管如此,我仍然可以在您的代码中识别出感觉奇怪的“外星人”对象。解决这个问题的一种方法是用你自己的观点来划分它。如果你没有改变你的子类中的任何东西,这看起来有点奇怪,但是这只在该类的源代码中可见,并且在你使用它的地方,它一直被命名。此外,只要您找到自定义点添加功能,它就会开始寻找真正的智能。

+3

有额外的依赖关系(这里是包含'System.Drawing.Point'的程序集,也是一种额外的行李箱。 – 2010-08-18 12:14:27

+0

是的,取决于你的额外编码成本与行李相比的“重量”如果是Point, – Nicolas78 2010-08-18 12:34:30

1

如果你的目的不是与绘画相关,我认为你做对了。在代码中使用一个System.Drawing.Point,它根本不会做任何与绘图有关的东西,可能会让人们误认为它被用于某些绘图功能。

6

我不同意到目前为止的其他答案,并说它确实很重要。 Point示例是一个简单的示例,但通常在上下文中未使用类的设计可能会产生不良影响。

一个类可能只针对特定用例实现,例如,不支持线程安全性,需要在框架中使用或暴露代码中不需要的功能。

当部署较新版本的程序集时,它可能会特别导致问题,该版本不再与您使用它的方式兼容,或者较新版本带来额外的成员和依赖关系,而您不想拥有该程序在你的代码中。

+0

可悲的是我不能接受两个答案 – Joey 2011-01-12 11:06:04

+0

我同意这个问题在一个相关的话题上,我不想指出评论“不要重新发明车轮”。意味着跨命名空间和构建意大利面代码,这意味着如果代码已经存在(您可以控制),并且这对两个项目来说很常见,将它抽象为更高级别的名称空间以供重用。如果它不是相同的命名空间,而不是那么常见,以至于可以做到这一点,那么为什么你要共享代码呢?在这个例子中,正如你的答案中所暗示的那样,使用它的代码可能会要求它改变以更多的方式使用,并且将打破任何其他人的使用克它。 – Suamere 2014-05-27 13:49:29

1

我最近在类似的情况。不需要Point类,但我将以此为例。

我做了我自己的Point类,因为System.Drawing.Point使用整数,当我需要双打的时候。后来我意识到这是一个好主意,即使我只需要整数,因为我可以根据需要扩展该类,并添加方法,接口和属性等。而我不应该能够使用系统.Drawing.Point。

有一个原则,你不应该在你的程序中重复知识,但在某些情况下,比如这个,它是无法避免的。


至于暗示引用另一个组件,你可以这样做:

using Point = System.Drawing.Point; // or whatever your namespace is called 
+0

对于'double's,有System.Windows.Point。它来自另一个程序集和另一个子系统(WPF)。 – Joey 2010-08-18 13:47:39

+0

糟糕!不知道那个。 – Nobody 2010-08-18 13:51:14

0

我会担心的因为在功能上和概念上(它是如何描述的命名空间带来的东西非常少在文档中)它符合目标。

虽然我可能会毫不犹豫地引入新的程序集。在这种情况下,Point很快就可以滚动自己的事实,我可能认为这样做的麻烦少于为我正在编写的程序集添加另一个依赖项的麻烦。否则,只要我没有将它用作Key(GetHashCode impl。in点在碰撞例如所有{0,1},{1,0}, {2,3}和{3,2}如果你有很多低值或矩形分布点)我会用它。