One module per class, bad idea?

[Erik Johnson]

    There are arguments of preference to be made on both sides. I think the
question largely comes down to what is "workable" and "maintainable". To
answer the original question, I think it is not necessarily a bad idea to
have one class per file. But if your classes are small, or certain classes
are logically related to other classes (e.g., one class is a subclass of
another, or one class is implemented in terms of another, or the two classes
work together to accomplish some task and it wouldn't make much sense to be
using just one of the classes), it makes a lot of sense to keep them
together in the same file.  If your classes are only a few dozen lines,
making lots of files may be more of a pain than having the code together in
one file.

    Where I work, we started with a set of classes that provided a layer of
abstraction and encapsulation to accessing our database tables. An object
was basically just a loaded DB record and generally didn't provide a lot
else. As time went on, we started to code more and more logic into these
classes that provided various functions to make it easy to load records, do
certain kinds of computations and filtering with them, to generate the SQL
to do the insert for the record, etc.

    The file has now grown into a 6800 line beast (including docstring,
whitespace, and CVS history).   Pretty much any time we implement some new
functionality, there are at least a few changes in that file. When you have
multiple developers working on different projects, and they all need to be
making changes to that file, the chances for someone making a merge error
goes up.  So, we are obviously at a point where that file needs to be split
up, but there are lots of other files that import and use the one file, so
it is a task that has been put off.  In retrospect, I wish I has started
things under a one class per file strategy, but at the time, it didn't make
a lot of sense to split those things up and I didn't anticipate the code
getting that big.

    So... there's no magic "one size fits all" answer here - do what makes
sense.

    As Carl points out, decent editors should be able to handle dispaying
different files. I use vim and know I can split the window (both
horizontally and vertically), editing either different sections of the same
file or different files and can cut and paste between the two windows. In
practice, I usually just jump between places in the same file under a single
window, or I textually cut and paste between two separate vim sessions, but
if that's something you need to do a lot, you might want to invest a bit in
learning how to use split windows in your editor. Some of the documentation
for doing this under vim can be found here:
http://vimdoc.sourceforge.net/htmldoc/windows.html#:split  and here:
http://vimdoc.sourceforge.net/htmldoc/usr_08.html
 (I'm sure emacs can do this as well, but I don't know emacs.)  If your
editor can't handle similar tasks, you might want to consider getting a
better editor.

HTH,
-ej


"Carl Banks" <pavlovevidence at gmail.com> wrote in message
news:1166817152.414154.151390 at 42g2000cwt.googlegroups.com...
> Kent Johnson wrote:
> > Carl Banks wrote:
> > > Now, I think this is the best way to use modules, but you don't need
to
> > > use modules to do get higher-level organization; you could use
packages
> > > instead.  It's a pain if you're working on two different classes in
the
> > > same system you have to keep switching files; but I guess some people
> > > prefer to switch files rather than to scroll for some reason.
> >
> > That would be me. I strongly prefer to switch files rather than scroll.
> > I use an editor that makes it easy to switch files. For me it is much
> > easier to switch between files than to scroll between two parts of a
> > file, and I don't lose my place when I switch back. I like to be able to
> > see things side by side.
>
> Man, I don't know you do it.
>
> Say I'm sitting there concentrating on programming something, and I see
> that I'll have to make a change in another file.  All of a sudden, I
> have to recall some filename out of thin air.  Totally breaks my train
> of thought, sometimes I space out trying to think of it because I have
> to cold-start an entirely different part of my brain.  It's less of a
> mental distraction to just scroll.
>
> I'm in the habit of changing things as soon as the need arises.  If I'm
> editing A and I see that I'll have to make a change in B, I stop
> editing A, change B, then come back to A.  For me, it results in MUCH
> fewer forgotten changes (YMMV).  But it also means a lot of switching.
> Consequently, trying to minimize distraction during switches is
> important to me.  Maybe it isn't if you switch less frequently, and
> rarely while in the middle of somthing.  I wonder if there's any
> correlation between how often one switches location, and preferrence
> (tolerance) for file size.  I bet the more often one switches location,
> the more likely they are to prefer larger files.
>
> (BTW, any decent editor will let you view different positions of the
> same file side-by-side.)
>
>
> > So I do tend to put classes in separate modules. Not always - when two
> > or more classes are closely related or a class has one or more helper
> > classes they may share a module - but in general my major classes are
> > each to a module.
> >
> > It does make the imports look funny - I tend to give the module the same
> > name as the class, Java style, so I have
> > from foo.bar.MyClass import MyClass
> > but that is a minor point IMO.
>
> I'd consider using all lowercase for the module.  Of course it doesn't
> make sense to come up with a unique name for modules when they're
> mostly one-to-one with classes, but it's still nice to give users a
> clue whether they object they're looking at is a class or a module.
>
>
> Carl Banks
>