is it a good idea to have classes with the same name in different namespace in c#?

Question

for example, we have two classes for parsing the resumes, one to parse Excel and the other to parse HTML.what my colleagues love to do is to name these two classes the same name and put them into different namespace,like shown as below:

namespace XX.ResumeParsers.Excel
class ResumeParser{}

namespace XX.ResumeParsers.Html
class ResumeParser{}

I feel it is not a good idea, I'll prefer to rename the classes, and put them into one namespace(but in different files if needed):

//in Excel folder under ResumeParsers folder
namespace XX.ResumeParsers
class ExcelResumeParser{}

//in Html folder under ResumeParsers folder
namespace XX.ResumeParsers
class HtmlResumeParser{}

thus, the Hierarchy still exists in the folder, but the namespace is the same(do not match the folder hierarchy exactly), is that OK?

and if I am right, any idea how to persuade my colleagues? or is there any significant drawback in their solution?

thanks.

Vevay

as per Jon, there're 2 decisions here: 1,Whether they should be in different namespaces or not is a separate decision. 2,keep the class name unique whenever possible - particulary when they are both used from the same consumer. – Vevay

Answer 1

It's not usually a good idea, no - particularly if you need to use both classes from the same code. Whether they should be in different namespaces or not is a separate decision, but I'd definitely call them HtmlResumeParser and ExcelResumeParser instead of trying to make the namespace communicate context. It will make it much easier to determine exactly what you're talking about when reading code.

Saltwater

Answer 2

I can tell from experience - worked on a large codebase involving a similar example - that the second option is much better in terms of readability. In my case, I would love to get a hold of the programmer that chose to do it the other way around :).

In general, for people writing the code, it's always clear which class is being used and why - but think about people reading it - will they be able to tell at a glance which parser is used in your code?

There's also the case when you need both classes in the same method - Jon already mentioned it - you'll get conflicts then and will need to use the full namespace - which is a pain. And even if you know you don't - somebody else in the future might need to. And will probably want to get a hold of you, too :).

Vesuvian

Answer 3

There isn't any absolute right or wrong here, but putting similar classes in the same namespace seems like a good idea.

You can look at the StreamReader and StringReader as a similar example in the framework. They both imlplement the same interface (TextReader), and are both in the System.IO namespace, eventhough the StringReader class isn't doing any actual I/O as it reads from a string in memory.

Regardless of whether you put the classes in the same namespace or not, you should try to make the class names unique. If you ever need both classes in the same file, it's a hassle to have to specify the full namespace all the time.

Boreas

And also you can look at Soap and Binary formatters and you will see that thay have different namspaces. And I think my example is more applicable for this question :) – Bouffant

I like Jon Skeet's point: whether or not they should be in different namespaces is another division. "you should try to make the class names unique",that's my option too. thanks to you all. – Vevay

Answer 4

I'd say it's probably OK if any given code will use either one or the other but not both, and if the two are implemented in separate assemblies. If they're in the same assembly, or if one class will want to use both, then I'd prefer distinct class names.

Wetzell

Answer 5

If parsers have one base interface and some specific helper classes, but used only over base interface, first solution (different namespaces) is best. Because:

• Can be divided on different assemblies
• Each parser independent from other

Bouffant

but even if you name the classes HtmlResumeParser and ExcelResumeParser, you can divide them into different assemblies too. – Vevay

Having them in the same namespace doesn't keep you from putting them in separate assemblies and thus making them independent. – Boreas

And you may have problem to give the different name for this assemblies, ofcourse if you whant to provide namespace to file name. – Bouffant

In what way does the name decide whether the parsers are independent from each other? – Saltwater

You must add using if you whant to reuse logic of one parser for another. And as result have more control on dependencies between pasrsers. – Bouffant