Should a class have the same name as the namespace

Question

I'm designing a namespace to hold a set of classes that will handle user related tasks for a several different applications. (Log-in, authenticate etc)

The problem is the namespace will be called Fusion.User but then it requires a class in that namespace that makes sense to call User.

Should you have a class with the same name as the namespace? Or am I taking the wrong approach here?

Answer 1

There are instances where using the same name will cause problems. One that leaps immediately to mind is when consuming a WCF service. When I did this recently in a class called "someBehaviour" in the namespace "companyName.someBehaviour" to consume "MyService", the compiler barfed on me saying that MyService didn't exist within the someBehaviour namespace. Changing the class name to something different (and vastly more useful) solved the issue and allowed me to compile the assembly.

Answer 2

The namespace is Fusion.User
Class Full Name would be Fusion.User.User

It is a good practise to keep them different because

1. It avoids confusion to the developer

2. It also looks ugly in some cases like here we are using two user.

   using Fusion;
   namespace xyz {
   public class test
   {
   User.User userObject {get;set;}
   }
   }
   So the better option would be to use different names

Answer 3

I'd probably call the name space 'usertasks' to avoid any confusion. You are going to have to qualify the inner class using the namespace regularily to avoid confusing the compiler.

Answer 4

Having class named in the same way as the name space (package) may lead to a thought that class is central to the package. But if I get it correctly User is just a data object in your case.

As far as I see you have 2 options:

1. Name your name space differently e.g. Fusion.Security
2. Use suffix for class name indicating its purpose e.g. UserDTO, UserAction etc.

Answer 5

See Do not name a class the same as its namespace post of Eric Lippert(MSFT)