CODEWITHSUNDEEP
c#.netnamespaces
CodeTherapist
CodeTherapist

Reputation: 2806

Namespace design and class separation

I have problem to find a good namespace design and class order. Imagine we have the following namespace hierarchy:

    MyCompany.Hardware
       - ClassA

    MyCompany.Hardware.DeviceType1
       - ClassB : ClassA

    MyCompany.Hardware.DeviceType2
       - ClassC : ClassA

    MyCompany.Hardware.Reader
       - ReaderClassC : Reader

Questions:

  1. Should I put the base classes always in the parent namespace? Or in the child namespace and the concret implementations in the parent?

  2. Should the ReaderClassC be in a separate or in the same namespace MyCompany.Hardware.DeviceType2? Or should I prefer the parent namespace for 'fast' access?

  3. Forget all the namespaces and put all into one (MyCompany.Hardware)?

Hoppefully you understand what I try to get out. It would be great if you can tell me about your namespace design.

Upvotes: 1

Views: 1536

Answers (3)

Aaron Anodide
Aaron Anodide

Reputation: 17186

This is all just my ad-hoc advice assuming your relatively new to object oriented programming. I think your question touches an area of design that is subject to debate and programming style choices.

That said,

One of the main goals of namespaces is to group up your types so they can easily be reused by other "clients" or programs that reference their containing class library.

With that in mind, you could start out with just one namespace for simplicity and introduce namespaces when they add value.

One place they might not add value in your example is DeviceType1 and DeviceType2. In my experience these would belong in the same namespace.

namespace Acme.Hardware {
   class Product 
   {
      public int Price { get; set; }
      public bool InStock { get; set; }
   }
   class Hammer : Product
   {
   }
   class ScrewDriver : Product
   {
   }
}

As an example of how coding style and namespaces intersect, notice how I used the very generic name Product as opposed to HardwareProduct. I went with a generic name here because I knew that name would be used by an inclusion of using Acme.Hardware or fully qualified Acme.Hardware.Product. In either case, there is contextual information near by.

In general I'd focus on classes first (i.e. their functionality and implementation) and namespaces secondarily, thinking of them as just a useful way to group up classes.

Upvotes: 1

Bartosz
Bartosz

Reputation: 3358

It depends on other definitions - namespaces are useful when you've got lots of types around, so if your, let's say, ClassB is accompanied with lots of stuff related to Hardware1 then it makes perfect sense to have inner namespace for this.

Ideally, you should just follow the logical grouping. You asked about ReaderC, if it relates to DeviceType2 and not to others, then it should not be in parent namespace, and if ClassA is base for all hardware types, then it needs to be in parent namespace as well.

Upvotes: 0

Erre Efe
Erre Efe

Reputation: 15557

As usual it's a matter of taste.

I prefer to use your fourth approach since it's a little cleaner (for me). I mean, if I'm using a Reader then I depend on using that namespace.

Of course you can give a look to the Namespace Naming Guidelines and particularly:

A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.

Upvotes: 3

Related Questions