Best practices for grouping namespaces, classes, etc

[_DD]

I believe Balena's Best Practices book suggests grouping quite a few
classes into each namespace. I don't remember a number, but this has
me curious about how other programmers handle this.

If classes are obviously related, then I use the same namespace.
Problem is that this doesn't seem to happen often. I could understand
Balena's numbers in the context of a specific library, but in the
scope of a large program, many corners are covered. I often end up
with a single namespace per project.

I also often end up with only a couple classes per project. This
happens for a different reason: I often run into occasions where
projects end up cross-dependent, so they need to be split up. Of
course that forces the size of each project to be smaller.

Comments? How many classes do you end up with per project?
How many classes or projects per namespace?

[Michael Nemtsev]

Not the number of classes, but their context and logic are major factors for
decoupling classes into different namespaces.
Even if you have 5-7 classes in single app you divide them by context. For
example. classes that are responsible for UI should be detached from those
that are responsible for you logic, and these ones in its turn detached for
Input/Output (data logic) classes

I believe Balena's Best Practices book suggests grouping quite a few
classes into each namespace. I don't remember a number, but this has
me curious about how other programmers handle this.

If classes are obviously related, then I use the same namespace.
Problem is that this doesn't seem to happen often. I could understand
Balena's numbers in the context of a specific library, but in the
scope of a large program, many corners are covered. I often end up
with a single namespace per project.

I also often end up with only a couple classes per project. This
happens for a different reason: I often run into occasions where
projects end up cross-dependent, so they need to be split up. Of
course that forces the size of each project to be smaller.

Comments? How many classes do you end up with per project?
How many classes or projects per namespace?

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[_DD]

On Mon, 15 May 2006 23:39:01 -0700, Michael Nemtsev
<Mi************@discussions.microsoft.com> wrote:

Not the number of classes, but their context and logic are major factors for
decoupling classes into different namespaces.
Even if you have 5-7 classes in single app you divide them by context. For
example. classes that are responsible for UI should be detached from those
that are responsible for you logic, and these ones in its turn detached for
Input/Output (data logic) classes

Thanks for your reply, Michael. Yeah, I was curious about how others'
projects end up as far as namespace density. I often end up with one
file per namespace, as you'd expect in some cases, but the only 'Best
Practices' info that I've seen that addresses this (Balena's book)
seems to imply that the average 'solution' will have many more than
I've ended up with. I also expect that to vary by type and diversity
of project

Sometimes I may take the 'context' categorization to too fine a level.
Just wondering about others' thoughts on organizing..

I also often end up with only a couple classes per project. This
happens for a different reason: I often run into occasions where
projects end up cross-dependent, so they need to be split up. Of
course that forces the size of each project to be smaller.

And this gets awkward. The usual thing that I've run into is...
Classes need interfaces as a low-level construct. Then the working
classes are built according to that. Then a top-level class (factory,
whatever) makes use of the working classes, referring to them by
interface.

Basically that results in the lowest and highest strata being built to
an abstraction (Interfaces), with the practical 'worker'
implementation classes in the middle. Fine, except that I'd love to
group the interfaces and factories together into one project--they do
belong together. But alas... circular dependency. This seems like it
would happen a lot.

[Helge Jensen]

_DD wrote:

On Mon, 15 May 2006 23:39:01 -0700, Michael Nemtsev
<Mi************@discussions.microsoft.com> wrote: Thanks for your reply, Michael. Yeah, I was curious about how others'
projects end up as far as namespace density. I often end up with one
file per namespace, as you'd expect in some cases, but the only 'Best
Practices' info that I've seen that addresses this (Balena's book)
seems to imply that the average 'solution' will have many more than
I've ended up with. I also expect that to vary by type and diversity
of project
I would say that "best-practice" depends very little on the number of
elements in the namespace, but on whether grouping or isolating on the
namespace level makes it easier to read. If there are many members in
the namespace you can go looking for groups, but don't look harder than
nessesary :)

Don't introduce namespaces to reduce the number of elements, apply
namespaces where grouping is natural.

One example of the "5-7 elements in a group" rule being applied
completely out of scope is the WinXP default ControlPanel, where more or
less random groupings have been done to lower the amount of elements in
the control-panel. That does *not* make it easier to find an element, it
makes it *harder*.

Basically that results in the lowest and highest strata being built to
an abstraction (Interfaces), with the practical 'worker'
implementation classes in the middle. Fine, except that I'd love to
group the interfaces and factories together into one project--they do
belong together. But alas... circular dependency. This seems like it
would happen a lot.

That circular dependency is created by your design. You are depending on
a 1:1 correspondence betweeen interface and implementation, right?
Your factories are bound to a specific implementation of the interface,
and thus reference that implementation.

Should you wish for more decoupling, declare interfaces for the
factories and use registration for them:

=== interface assembly ===
interface ITFactory {
T produceT(...);
}
public class TFactory {
public static Instance;
}

=== implementation assembly ===
public MyTFactory: ITFactory {
T produceT(...) { ... };
}

=== usage ===
ITFactory tproducer = TFactory.Instance;
// this code has *no* idea about how ITFactory is implemented
// and can be in any assembly.
// Works if *anyone* have set TFactory.Instance
tproducer.produceT(...);

=== anywhere, before usage ===
if ( InOneMind )
TFactory.Instance = new MyTFactory();
else
TFactory.Instance = new SomeOtherTFactory();


--
Helge