Why NOT only one class per file?

Bruno Desthuilliers bdesth.quelquechose at free.quelquepart.fr
Tue Apr 10 19:13:43 EDT 2007


Sherm Pendley a écrit :
> Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> writes:
> 
> 
>>Sherm Pendley a écrit :
>>
>>>Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> writes:
>>>
>>>
>>>
>>>>Sherm Pendley a écrit :
>>>>
>>>>In my book, it's huge classes and methods that are usually a smell of
>>>>a design problem.
>>>
>>>
>>>Obviously we're reading different books.
>>
>>Obviously. But I didn't gain this knowledge from books.
> 
> 
> Obviously, you have no sense of humor.

Obviously, we don't have the same sense of humor.

>>FWIW, I'd be interested if you'd let us know about any book pretending
>>that monster classes are good design !-)
>  
> You've already decided that "monster classes" are bad design,

I came to this conclusion from my own experience, and it seems that 
quite a few other programmers (most of them either better and/or more 
experimented than me) came to the same conclusion. But feel free to 
believe it's an a priori if that makes you feel better.

> and that
> anything conflicting with your belief is mere pretense. Why should I waste
> my time debating when you've already made up your mind?

Then don't. But I'd still be interested if you could let us know about 
any book advocating monster classes as good design.

>>>But that's OK - I'm not on a crusade to convince everyone to work my way.
>>>If "one class per file" doesn't work well for you, don't write that way.
>>>All I'm saying is, what works well for you isn't necessarily what works
>>>well for everyone.
>>
>>It seems that it works well for almost anyone having some real-world
>>experience with languages like Python.
>  
> I didn't say otherwise.

So let's rephrase your previous assertion :
"what works well for almost anyone having some real world experience 
with languages like Python isn't necessarily what works well for 
everyone" (implied : "... when using a Python-like language" - this 
seemed obvious but it may be better to state it more explicitly, just in 
case...).

> You're arguing a false dichotomy;

Nope, just stating a fact - from which you may or not derive some 
conclusions.

> the fact that one
> approach works well does not prove that others won't work equally well.

The fact that a in a given context a significant majority of 
experimented users usually favors one approach over the other might be 
taken as an indication that there might be some reason for this.

About "proofs", I'm afraid that "proving" things learned from experience 
can be sometimes difficult - or at least above my own skills, specially 
in a language I'm not very fluent with. But I think I did tried (perhaps 
unsuccessfully, but that's another problem) to back my POV, instead of 
just resorting to rethoric like you're doing here.

> I'm
> not saying that your preferred style is wrong; I'm just saying that it's a
> matter of preference, not a universal truth.

If it was only *my* "preferred style", I wouldn't even argue. Now I'm 
not presenting it as a "universal truth", but as the result of 
experience (and not only my own) with a given class of languages.

Asserting that one should *always* only put one class per file is just 
as non-sensical as asserting that one should *always* put several 
classes in a same file. Not only because Python doesn't requires you to 
use classes, but mostly because it's arbitrary and dogmatic. You seem to 
have (dis)missed the point where I said that I *almost* never had a 
single class in a file - which implies that I *sometimes* do this - when 
it makes sens from either a practical or logical POV.

FWIW, I would certainly not try to apply this "preferred style" when 
writing GUIs in C++. You see, the fact that some idiom (style, whatever) 
works well with a given (class of) language(s) doesn't mean it's the 
more effective in some other context. Here again, it seems that you 
(dis)missed the point where I asked you if your thousands-lines-long 
classes were written in Python.



More information about the Python-list mailing list