Proper use of "namespace"

[Zathras]

I have recently been given the task of enhancing a rather large application. At least it looks large to me with 49 .vb source files over half of which are forms.

This is the first time working with vb.net although I have worked with VBA, C# and Delphi. I'm sure to have many questions, but first I would like an opinion, please...

All of the source files contain code that declare the same namespace. (There are a few exceptions, but 95% of the code is in the same namespace across 49 files.) Was this a reasonable thing to have done? Or would it be better to have each form in its own namespace?

It looks as if it was done this way so that everything could access one common class which is a sort of a do-it-all class using Public Shared properties and functions. (It is never instantiated.) Which leads to a second question: Isn't that the same as using Global variables?

If these are standard industry practices, I guess I will just have to learn to live with them but it doesn't feel right to me. It feels like that the object-oriented features of VB.NET were completely by-passed and the result is nearly unmaintainable. I tried using Project Analyzer v8.1.01 from Aivosto to get a handle on it, but it shows lines and arrows going every which way.

I tried a Google search but couldn't find this addressed. I also searched in this forum with the same negative result. They are willing to say how to use the Namespace directive syntactically, but I couldn't find any advice on how to use it logically.

Opinions, please?

 

[cjelec]

Imho, namespaces tend to be used in situations where you (or someone else) are going to use classes outside of the original app.

Namespaces give a larger group name to a collection of classes and objects, and (also imho) you use namespaces named after your company or main project.

Your app's name will automatically be the namespace to all the classes and object within it. You will see this in the class view in vs.

 

[computerjin]

Zathras,

What exactly is a namespace?

Everybody knows that the fundamental unit of OOP is a “class”. To develop an application, you are free to declare and define any number of classes. When you are dealing with too many classes, sometimes, it may be necessary for you to categorize them in a meaningful manner. Just like you encapsulate a set of members into a class, you may need to have a “categorization of classes”.

A set of classes belonging to a particular category can be grouped into a “namespace”. It is a logical structure, which contains only classes/structures/modules in it. Just as a class has its own name, a namespace should also be defined with its own name (or instead, the category name of the classes!).

The .NET Framework Class Library has a huge set of pre-defined “namespaces” with thousands of “classes” hierarchically designed. Let us consider the following statement:

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

According to the above statement, you are trying to execute a method named “WriteLine” (which is “shared”) in the class “Console” available in the namespace “System”. When we use the statement “Imports”, we are actually importing all the classes available within the respective “namespace”. Don’t forget that a “namespace” can also be nested with several other “sub-namespaces” (ex: System.Web.UI etc.)

Because a namespace is a logical thingie, it may contain more than one classes implemented in more than one physical files. Multiple assemblies can use the same namespace. Visual Basic treats them as a single set of names. For example, you can define classes for a namespace called SomeNameSpace in an assembly named Assembly1, and define additional classes for the same namespace from an assembly named Assembly2.

My Advice: Analyse the code and decide yourself whether it is suitable to put everything in one namespace or it is better to categorized your classes in multiple namespaces and sub-namespaces. It is not always desireable to put every class in different namespace. Categorize your classes logically by analyzing data flows, process inter-relations etc.

Answer to 2nd question: No, Shared members are NOT same as global variables. An excellent info link is here for you: Shared Members and Instance Members in VB.NET

Hope it helps.

 

[Zathras]

Thanks. Not exactly the answer I was hoping for, but plenty of food for thought.