One module per class, bad idea?

[Carl Banks]

Gabriel Genellina wrote:
> At Friday 22/12/2006 20:25, Paddy wrote:
>
> >Are there tools out their to help with the refactoring task of
> >splitting a module into two or more sections then showing what other
> >files need to change?
>
> Usually no other files need to change. Ex: you have BigOldModule
> including ClassA, ClassB and FunctionC. Move each one onto its own
> module, perhaps including a subset of the original imports of BigOldModule.
> Shrink BigOldModule to just:
>
> from ClassA import ClassA
> from ClassB import ClassB
> from functionC import functionC
>
> and maybe a few other things, so all imports from the outside remain
> the same. That's all - most of the time.

I wouldn't recommend this unless it's important not to change the
external usage.  If you're doing it just to save work in refactoring,
it's a partial solution hack that'll lead to more confusion and delay a
real solution even more.


Carl Banks