Namespace-class hierarchy for a library of helper functions

[Anton Shepelev]

Hello all,

I have asked this elsewhere but, not getting any
help, am posting it here.

I should like to consult you on a problem of design.
I am working on a namespace hierarchy for a large
set of assemblies implementing a library of static
classes whereof one may think as helper utilities
for the sake of the discussion.

I have already decided to use a separate namespace
for each assembly to simplify the finding of which
class is in which file, but as regards the nested
namespaces inside the file's main one I am in doubt.

What troubles me is the frequent case of a class's
exporting methods that require parameters of a spe-
cial types -- structs, enums, and delegates -- which
are used only within that class and nowhere else. I
do not want to define these types inside the class
because the caller will always have to qualify them
with the class name, which is unnecessarily verbose.
On the other hand, declaring those types on one lev-
el with the class will clutter the namespace: imag-
ine five classes and twenty types jumbled together,
where each type belongs only to one class.

So I thought about wrapping the class and its type
declarations into a nested namespace as shown below.
NS for namespace, C for class, and T for type:

NS1:
C1,
T11..T1n;
NS2:
C2,
T21..T2n;

It might be a little overhead but does not have nei-
ther the verbosity (types declared inside classes)
nor the clutter (type and class on one level) men-
tioned above, and I think it is more scalable, i.e.
better fit for adding more classes and types, but a
problem of naming arises. One is tempted to have
eponymous class and namespace, but then one must use
an alias to access the class efficiently, and other-
wise what sensible name can the namespace have? For
a TableOperations class, should the namespace be
TableOperationsStuff? Seems ugly.

My confusion might be understood better if I told
that I have a background of classic procedural lan-
guages where this problem did not exist. In Pascal
one would "use" a unit with all its functions and
types together, while in Modula-2 one would "import"
public functions from other modules selectively, and
no name qualification was required in either case.

If you have encountered similar problems, how did
you deal with them?

 

[Arne Vajhøj]

I should like to consult you on a problem of design.
I am working on a namespace hierarchy for a large
set of assemblies implementing a library of static
classes whereof one may think as helper utilities
for the sake of the discussion.

I have already decided to use a separate namespace
for each assembly to simplify the finding of which
class is in which file,

That is rather standard and used by MS themselves.

but as regards the nested
namespaces inside the file's main one I am in doubt.

What troubles me is the frequent case of a class's
exporting methods that require parameters of a spe-
cial types -- structs, enums, and delegates -- which
are used only within that class and nowhere else. I
do not want to define these types inside the class
because the caller will always have to qualify them
with the class name, which is unnecessarily verbose.
On the other hand, declaring those types on one lev-
el with the class will clutter the namespace: imag-
ine five classes and twenty types jumbled together,
where each type belongs only to one class.

So I thought about wrapping the class and its type
declarations into a nested namespace as shown below.
NS for namespace, C for class, and T for type:

NS1:
C1,
T11..T1n;
NS2:
C2,
T21..T2n;

It might be a little overhead but does not have nei-
ther the verbosity (types declared inside classes)
nor the clutter (type and class on one level) men-
tioned above, and I think it is more scalable, i.e.
better fit for adding more classes and types,

I agree.

But for a slightly different but still compatible reason: the
fact that the classes does not share types indicate that they
are not closely related and therefore should not be in the same
namespace.

but a
problem of naming arises. One is tempted to have
eponymous class and namespace, but then one must use
an alias to access the class efficiently, and other-
wise what sensible name can the namespace have? For
a TableOperations class, should the namespace be
TableOperationsStuff? Seems ugly.

I would probably use something like:

namespace = YourCompany.YourProduct.TableOperations

class = TableOperationsUtil or TableOperationsHelper

that convention is frequently seen for static classes
with utility/helper methods.

I think most C# developers would find it easy to
understand the code.

My confusion might be understood better if I told
that I have a background of classic procedural lan-
guages where this problem did not exist. In Pascal
one would "use" a unit with all its functions and
types together,

The Delphi flavor of Pascal.

But to me the Delphi use of unit seems very similar to
C# reference and using.

while in Modula-2 one would "import"
public functions from other modules selectively, and
no name qualification was required in either case.

Modula-2 is in many ways a great language.



One of the things that C# did not bring over from Java/C++
was the ability to import/using single classes.

Design choice. We would need to ask Anders Hejlsberg or one
of his closest to know why that decision was made.

Arne

 

[Anton Shepelev]

Thank you for the consultation, Arne.

The Delphi flavor of Pascal.

The Borland flavor, because even Turbo Pascal had
units.

But to me the Delphi use of unit seems very simi-
lar to C# reference and using.

Not so to me, because the addition of classes has
comlicated matters, especially when using static
methods.

 

[Arne Vajhøj]

Thank you for the consultation, Arne.


The Borland flavor, because even Turbo Pascal had
units.

True.

I am not familiar with Apple, but even the original
Apple Pascal may have had it.

Not so to me, because the addition of classes has
comlicated matters, especially when using static
methods.

Both Delphi and C# has classes.

Arne

 

[Arne Vajhøj]

True.

I am not familiar with Apple, but even the original
Apple Pascal may have had it.

But original Pascal, ISO Pascal and extended ISO Pascal does not.

Which was my point.

Arne