About one class/function per module

[Rhodri James]

On Mon, 02 Nov 2009 13:24:59 -0000, Peng Yu <pengyu.ut at gmail.com> wrote:

> Another advantage one of class/function per file is that the syntax
> clearly tell the dependence relation between classes and functions.

Um, no.  Grepping for "import" now tells you that there is a dependency
between the file contents, but it leaves you with no clue as to what
that relationship is.  You've thrown away the strong relationship
information that comes from collecting your source into a single file.

> Suppose I have class A and class B in a file, I can not easily figure
> out which class depends on which class by a simple script. However, if
> they are in two separate files, for example B depends on A, then I
> will have 'import A' in file B. This dependency can be easily figured
> out by a script.

You could always try searching for the class name, which will tell you
a whole lot more about how it's being used.

> The following scenario also demonstrate why the maintenance cost is
> lower with one class/function per file, because it decouples
> dependences. Let's suppose class A and B are in the same file. Now I'm
> changing class B. But while I'm changing class B, I just realize that
> I have to change A. But since the change in B is half way done
> (syntactical not correct), I will not be able to run the test case for
> A, because the test case import the file that has class B. In
> contrast, if A and B are in different files, even if B is half way
> done, I can still run test case for A.

Provided, of course, that the test case is still meaningful given the
changes being made to B, and that you don't forget what you were doing
with B while your attention is on A.  Not my favorite way of working,
though sometimes you just can't avoid it.

Of course, given that A and B are in different files, your chances
of realising that you needed to change A at all dropped dramatically.

-- 
Rhodri James *-* Wildebeest Herder to the Masses