Hello, Chris!

I haven't heard of any such best practices.

Based on my experience it is better to place classes on separate files. This
approach simplifies navigation when number of classes in the system is
large.
Also group of related classes can be placed into the same folder.

The information above is based on my personal experience.
--
With best regards, Vadym Stetsiak.
Blog: http://vadmyst.blogspot.com

You wrote  on Sun, 20 Jan 2008 12:59:03 -0800:

CL> Hi.

CL> What is the recommended way to organize the classes inside a VB.Net
CL> project? For classes that are logically related, I tend to put them
CL> on the same file and I read an article stating that when classes
CL> form an atomic unit of functionality they should be put on the same
CL> file. Is there any pattern on this subject?

CL> Best regards,
CL> Chris Leffer

CL> *** Sent via Developersdex http://www.developersdex.com ***

The method that will by far give the least headaches is one class per file,
pretty much independent of language. Even if a class is tied very closely to
another one (say MySuperSpecialCollection and MySuperSpecialCollectionItem)
it's still probably better to give them their own files, just because it
makes classes easier to find and allows for more granular maintenance. If a
class is tightly bound to another but not exposed to clients, consider
making it a nested class (these should be rare, though, as there are usually
better designs).

The problem with sticking together classes that are "logically related" is
that there's often more than one logical relationship. What goes with what,
then? A class should have a single responsibility, and its cooperation with
other classes should be a separate matter. Ditto for the "atomic unit of
functionality". Atomic on what level? A class should still make sense on its
own, and then you might as well give it its own file.

I've seen other approaches. Here are some ideas that you should definitely
consider *not* using:

- Placing all exceptions together in a separate file. People do this because
all those exception classes "get in the way". If that's a concern, just
using a new directory for them is still a better approach.

- Putting exception classes in with the class that produces them. This is
pretty arbitrary, because some exceptions will probably be thrown by more
than one class. If you give those their own file and leave some others
lumped in, you'll make it harder for people to find those lumped exceptions,
as they'll naturally look for a separate file first. It's not always obvious
which class is "responsible" for an exception.

- Grouping all enumerations in one file. This makes for nice reference
reading, but it's not good for maintenance, since any change to any enum
anywhere will mean this file will need updating. Unlike classes, however,
enums are almost always tied to a specific class and should be put in the
file of that class. This approach is less bad when the enumerations are part
of a protocol specification that will remain frozen for all eternity (or at
least change really infrequently) but these cases are not as common as you'd
think.

Of course, in the end, there's always the class view which makes the
organization of classes into files irrelevant. Not having to use that just
to find a class is still easier, though, as is not having to think about
where to put a class.

Well, I can't tell for VB.net,
but I believe general consensus for C# is one
class/struct/interface/whatever per file.

Exception I usually make is when only /one/ class uses particular
enumeration, then I tend to put this enumeration on top of the same file
that contains the class. If OTOH enumeration is used in various classes, it
deservers its own file.

LP,
Dejan