9

I'm trying to design a class library for a particular engineering application and I'm trying to ensure that my class & namespace naming conventions make sense.

I have the following situation:

namespace Vehicle{ class Wheel{...} //base class for Wheel objects class Engine{...} //base class for Engine objects ... namespace Truck{ class Wheel: Vehicle.Wheel{...} //Truck specific Wheel object class Engine: Vehicle.Engine{...} //Truck specific Engine object ... } namespace Car{ class Wheel: Vehicle.Wheel{...} //Car specific Wheel object class Engine: Vehicle.Engine{...} //Car specific Engine object ... } ... }

The code gets used in ways that all of these classes will need to be referenced from within the same scope. The following situation would be likely:

... Vehicle.Wheel.DoSomething(); Vehicle.Truck.Wheel.DoSomething(); Vehicle.Car.Wheel.DoSomething(); ...

Under these circumstances, am I better off giving the classes more specific names

namespace Car{ class CarWheel: Vehicle.Wheel{...} //Car specific Wheel object ... }

or leave the naming as shown in the first example and rely on the information that is encoded in the namespace for clarity? Under the latter approach, I assume I would want to utilize alaising for clarity in the code that makes use of this library, corret?

It seems redundent to have:

Vehicle.Car.CarWheel

or

Vehicle.Truck.TruckEngine

but I also want to have very descriptive and specific class names.

Philosophically, what I'm asking is whether or not to include the namespace as a part of the class name when considering if a class name is descriptive enough.

Improve this question

2 Answers 2

Reset to default
22

Typically namespaces are pluralized, so as not to collide with class names (e.g. it is likely you would want classes named Vehicle and Car) so I'd be inclined to use namespaces as follows:

namespace Vehicles; namespace Vehicles.Cars; namespace Vehicles.Trucks;

As for the names of classes, it would be typical to prefix the class name with the specialization, especially if they are likely to be used together, so you'd end up with something like:

class CarWheel : Wheel class TruckWheel : Wheel

You can see this type of 'redundancy' everywhere in the .NET Framework, for example in the System.Xml namespace virtually all classes are prefixed with Xml, or in the System.Data.SqlClient namespace most classes are prefixed with Sql. It means that you can import namespaces with the using directive and then not have to fully-qualify class names throughout your code, e.g. which of the following is more readable?

Vehicles.Cars.Wheel wheel = new Vehicles.Cars.Wheel();

or

CarWheel wheel = new CarWheel();

It's obvious what both are doing, but the second is considerably shorter.

Note that if you do include the specialization in the name, then you may find that you don't need all the nested namespaces (.Cars, .Trucks, etc.) which can become painful if they are usually used together, and so every file using them would have to import all the namespaces, e.g.

using Vehicles; using Vehicles.Cars; using Vehicles.Trucks; using Vehicles.SomethingElse; using Vehicles.YetAnotherThing;

If you find this same stack of using directives is at the top of each file, then collapse the classes down into a single namespace. You typically include all related functionality that is expected to be used together in a single namespace, and only use nested ones for functionality that extends the base namespace but is less frequently used.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

The "typically pluralized namespaces" bit helped me greatly - thanks!
4

I would try to avoid reusing names across different namespaces, particularly if a client may want to use both in the same program.

Do you really need a namespace for Car, Truck etc? All these namespaces sound more like they ought to be classes than namespacese. Perhaps in your real situation it makes more sense though...

Improve this answer

1 Comment

Yes, I see your point. I think the situation that I actually have is a little different but the domain I'm working in has terminology that would be very hard to understand without a lot of background knowledge. In my case the namespaces make sense as namespaces rather than classes.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.