C# Programming/Namespaces

From Wikibooks, open books for an open world
Jump to: navigation, search

Namespaces are used to provide a "named space" in which your application resides. They're used especially to provide the C# compiler a context for all the named information in your program, such as variable names. Without namespaces, you wouldn't be able to make, e.g., a class named Console, as .NET already uses one in its System namespace. The purpose of namespaces is to solve this problem, and release thousands of names defined in the .NET Framework for your applications to use, along with making it so your application doesn't occupy names for other applications, if your application is intended to be used in conjunction with another. So namespaces exist to resolve ambiguities a compiler wouldn't otherwise be able to do.

Namespaces are easily defined in this way:

 namespace MyApplication
 {
     // The content to reside in the MyApplication namespace is placed here.
 }

There is an entire hierarchy of namespaces provided to you by the .NET Framework, with the System namespace usually being by far the most commonly seen one. Data in a namespace is referred to by using the . operator, such as:

 System.Console.WriteLine("Hello, World!");

This will call the WriteLine method that is a member of the Console class within the System namespace.

By using the using keyword, you explicitly tell the compiler that you'll be using a certain namespace in your program. Since the compiler would then know that, it no longer requires you to type the namespace name(s) for such declared namespaces, as you told it which namespaces it should look in, if it couldn't find the data in your application.

So one can then type like this:

 using System;
 
 namespace MyApplication
 {
   class MyClass
   {
     void ShowGreeting()
     {
         Console.WriteLine("Hello, World!"); // note how System is now not required
     }
   }
 }

Namespaces are global, so a namespace in one C# source file, and another with the same name in another source file, will cause the compiler to treat the different named information in these two source files as residing in the same namespace.

Nested namespaces[edit]

Normally, your entire application resides under its own special namespace, often named after your application or project name. Sometimes, companies with an entire product series decide to use nested namespaces though, where the "root" namespace can share the name of the company, and the nested namespaces the respective project names. This can be especially convenient, if you're a developer who has made a library with some usual functionality that can be shared across programs. If both the library and your program shared a parent namespace, that one would then not have to be explicitly declared with the using keyword, and still not have to be completely typed out. If your code was open for others to use, third party developers that may use your code would additionally then see that the same company had developed the library and the program. The developer of the library and program would finally also separate all the named information in their product source codes, for fewer headaches especially, if common names are used.

To make your application reside in a nested namespace, you can show this in two ways. Either like this:

 namespace CodeWorks
 {
     namespace MyApplication
     {
         // Do stuff
     }
 }

... or like this:

 namespace CodeWorks.MyApplication
 {
     // Do stuff
 }

Both methods are accepted, and are identical in what they do.