current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 14 down vote favorite
3

I have seen other developers using static classes as namespaces

public static class CategoryA
{
    public class Item1
    {
        public void DoSomething() { }
    }
    public class Item2
    {
        public void DoSomething() { }
    }
}

public static class CategoryB
{
    public class Item3
    {
        public void DoSomething() { }
    }
    public class Item4
    {
        public void DoSomething() { }
    }
}

To instantiate the inner classes, it will look like the following

CategoryA.Item1 item = new CategoryA.Item1();

The rationale is that namespaces can be hidden by using the "using" keyword. But by using the static classes, the outer-layer class names have to be specified, which effectively preserves the namespaces.

Microsoft advises against that in the guidelines. I personally think it impacts the readability. What are your thoughts?

share|improve this question
    
It's up to the implementer whether they need the namespaces present in the implementation. Why would you force the use of the namespaces (and fake namespaces at that) on them? –  Craige Nov 10 '11 at 14:45
    
May be for grouping purposes? Like there are a lot sub classes and by grouping the sub classes to static classes. That make the intension clear? –  user394128 Nov 10 '11 at 16:42
    
Would putting the sub classes in a sub-namespace not also make the intention clear? Also, this is the type of problem solved by documentation. –  Craige Nov 10 '11 at 17:24
add comment

migrated from stackoverflow.com Nov 10 '11 at 14:27

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 14 down vote

Using static classes as namespaces defies the purpose of having namespaces.

The key difference is here:

If you define CategoryA, CategoryB< as namespaces, and when application uses two namespaces : 

CategoryA::Item1 item = new CategoryA::Item1(); 
CategoryB::Item1 item = new CategoryB::Item1();

Here if the CategoryA or CategoryB is a static class rather than namespace, the usage for the application is almost same as described above.

However, if you define it as a namespace and application uses only 1 namespace (doesn't include CategoryB), in that case application can actually use following 

using namespace CategoryA; 
Item1 item = new Item1();

But had you define CategoryA as a static class the above is undefined! One is forced to write CategoryA.something every time.

Namespaces should be used to avoid naming conflicts whereas class hierarchy should be used when class grouping has some relevance to the system model.

share|improve this answer
    
+1 for remembering the using issue. I forgot that. –  zmilojko Nov 10 '11 at 17:11
    
Also, if someone wants to not use namespaces, even using classes the can: using Item1 = CategoryA.Item1 (i think that works for nested classes as it does for namespaces) –  George Duckett Jan 16 '12 at 12:44
    
In C++, ADL does not work with class scope; it works with namespace scope. So in C++, the namespace isn't only natural choice, but correct and idiomatic choice also. –  Nawaz Mar 8 '13 at 11:06
add comment
up vote 5 down vote

Whatever is going on here certainly isn't idiomatic C# code.

Maybe these others are trying to implement the module pattern - this would let you have functions, actions and so on as well as classes in the 'namespace' (i.e. static class in this case)?

share|improve this answer
    
I agree, looks weird. –  marko Nov 10 '11 at 21:27
add comment
up vote 4 down vote

First of all, every class should be in a namespace, so your example would actually more be like: 

SomeNamespace.CategoryA.Item1 item = new SomeNamespace.CategoryA.Item1();

That said, I see no benefit of this kind of code gymnastics when you can just as well define such a namespace:

namespace SomeNamespace.CategoryA { ... }

If you are maybe some day thinking of storing some static methods on upper class level, this could make sense, but still is not what C# creators have in mind, and might just make it less readable to others — I would waste a lot of time thinking WHY you did this, and thinking if I am missing some source file that would provide explanations.

share|improve this answer
    
So why are enums the exception to the rule? –  sq33G Nov 10 '11 at 15:12
    
That is a different question :) But I would still not define a static class just in order to define enums in it. –  zmilojko Nov 10 '11 at 16:21
add comment
up vote 1 down vote

Namespaces in Java, JavaScript and .NET related aren't complete, and only allow to store classes, but other stuff like constants or global methods, don't.

Many developers use the "static classes" or "static methods" tricks, even if some people don't recommended.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.