How important is the context that is implied by a namespace?

Question

Ok, the title might sound a bit vague but I really can't think of something clearer here.

I recently was in the position where I needed a Point class, simply with two properties, X and Y and a ctor Point(int x, int y). Nothing fancy. Now this thing already exists in .NET, but this was in a library that handled certain objects on a map and dragging System.Drawing into this just felt ... wrong somehow. Even though System.Drawing.Point fit what I needed perfectly, I now created that struct myself again in that project.

Now I wonder whether that was a right or sensible thing to do. System.Drawing.Point would have come with a reference to that assembly as well, if I remember correctly. And putting something in System.Drawing into a totally non-drawing related context was somehow weird.

Thoughts? What if it wouldn't have implied a reference to another assembly?

Answer 1

I wouldn't say that what you did was wrong however a namespace is really just a container for declarations within which each name is unique, the namespace name does provide some context to help you find the right function for your need but don't get hung up on the context not quite fitting your useage, if the object is ideal then it's ideal. Apart from the using statement you will probably never actively refer to the namespace again.

Answer 2

I would have just used the System.Drawing.Point. Why re-create something that already exists? Who cares what the namespace is called if provides the functionality you need. Just my 2 cents...

Answer 3

If you're not importing any "luggage" (like having to intialize stuff that you don't use) so it's exactly what you need, I'd go for the existing code. Just no point in recreating existing code. Chances are also that you may discover functions later on which perform functions you need and expect that particular class.

Still, I can identify with feeling strange having an "alien" object in your code. One way to get around this would be to subclass it with your own point. That'll look a bit strange if you're not changing anything in your subclass, but that's only visible in the source of that class, and where you use it, it's consistently named. Also it'll start looking actually smart as soon as you find yourself adding functionality to your custom Point.

Answer 4

If your purpose for the point was in no way drawing related, I think you did the right thing. Using a System.Drawing.Point in code which does nothing drawing related at all may confuse people down the line into thinking it's used for some drawing functionality.

Answer 5

I disagree with the other answers so far and say that it actually matters. The Point sample is a simple one, but in general using a class in a context it hasn't been designed for may have undesired effects.

A class may have been implemented for a particular use case only, e.g. no support for thread safety, requiring the use within a framework or exposing functionality that is unwanted in your code.

It might especially lead to problems when a newer version of the assembly is deployed, which is no longer compatible with the way that you use it, or the newer version brings additional members and dependencies that you don't want to have in your code.

Answer 6

The context of namespace is fundamental in approaching the precise function of a class; a Connection class is going to be a very different beast from one namespace to the next. Is a Web.Cache class going to be suitable for caching in other applications, or does it have a fundamental dependency on web infrastructure?

MSDN describes System.Drawing.Point structure as follows:

"Represents an ordered pair of integer x- and y-coordinates that defines a point in a two-dimensional plane."

With such a general description, it could be argued that this structure is only incidentally related to drawing and really belongs in a more fundamental namespace.

However, as it does live in System.Drawing, the implication is that it represents a point within a 2-dimensional drawing space. As such, using it for purposes other than drawing is mis-use of the class; it may function for your needs, but it is not being used for its original purpose.

Answer 7

I was in a similar situation recently. Not needing the Point class, but I'll use that as an example.

I made my own Point class because the System.Drawing.Point uses ints, when I needed doubles. I realised later that it was a good idea, even if I only needed ints because I can then extend the class as needed, and add methods, interfaces and attributes etc. Whereas I wouldn't have been able to should I have used the System.Drawing.Point.

There's the principle that you should not duplicate knowledge in your programs, but in some cases such as this one, it can't be avoided.

---

As for implying reference to another assembly, you can do this:

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

Answer 8

I would worry very little about bringing something in from the namespace given that both functionally and conceptually (how it is described in the docs) it fits the goal.

I might hesitate to bring in a new assembly though. In this case the fact that Point is so quick to roll ones own that I might consider the hassle of doing so less than that of adding another dependency to the assembly I was writing.

Otherwise, as long as I wasn't using it as a Key (the GetHashCode impl. in point isn't great in the way it collides for e.g. all of {0,1},{1,0},{2,3}and{3,2} if you have a lot of low-valued or rectanguarly distributed points) I'd use it.