namespace and class?

[Sender]

what's the difference b/w namespace and a class

 

[Cowboy \(Gregory A. Beamer\)]

Namespace is a logical grouping, class is physical. You cannot instantiate a
namespace to make an object, you can a class.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Tom Spink]

Hi Sender,

Think of a namespace as a bucket. This bucket holds classes.

Classes can contain code, namespaces can not contain code, but they contain
classes that contain code.

It's like the hip-bone's-connected-to-the-leg-bone:

Assemblies
Namespaces
Classes
Structures
Enums
Interfaces
Delegates

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations

 

[Herfried K. Wagner [MVP]]

what's the difference b/w namespace and a class

A class represents an entity (like a file in the file system).
Namespaces are used to structurize lots of classes something like
folders structurize the file system.

Have a look at this chapter in the documentation---it will provide an
introduction to object oriented programming with VB.NET.

<http://msdn.microsoft.com/library/en-us/vbcn7/html/vbconprogrammingwithobjects.asp>

 

[Sender]

Thank you all for your replied. Helpful.

 

[Scott M.]

One important aspect of namespaces is that they help to avoid class naming
collisions.

If you and I both work for the same company, but in different departments, I
might make a class called customer and you might also make a class called
customer. Now, my customer and your customer may have completely separate
uses and completely separate meanings, but the name we both chose happens to
be the same.

Now if a 3rd person in our company needs a customer class, should they use
yours or mine? How would that 3rd person know which is which?

By storing classes in namespaces, we can eliminate this problem. My class
could be stored in my departments namespace and so could yours.

AcmeCompany.HumanResources.Customer

....and...

AcmeCompany.Marketing.Customer

"AcmeCompany.HumanResources" and "AcmeCompany.Marketing" are the namespaces
and "Customer" is the actual class placed into the namespace.

Now that 3rd person in our company would have a better idea of which
customer class to use!

 

[Sender]

very good example.

One important aspect of namespaces is that they help to avoid class naming
collisions.

If you and I both work for the same company, but in different departments, I
might make a class called customer and you might also make a class called
customer. Now, my customer and your customer may have completely separate
uses and completely separate meanings, but the name we both chose happens to
be the same.

Now if a 3rd person in our company needs a customer class, should they use
yours or mine? How would that 3rd person know which is which?

By storing classes in namespaces, we can eliminate this problem. My class
could be stored in my departments namespace and so could yours.

AcmeCompany.HumanResources.Customer

...and...

AcmeCompany.Marketing.Customer

"AcmeCompany.HumanResources" and "AcmeCompany.Marketing" are the namespaces
and "Customer" is the actual class placed into the namespace.

Now that 3rd person in our company would have a better idea of which
customer class to use!