One module per class, bad idea?

[Carl Banks]

Gabriel Genellina wrote:
> At Friday 22/12/2006 22:58, Carl Banks wrote:
>
> > > 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.
>
> In some cases you may consider the fact that ClassA is contained in
> its own module, just an implementation detail, and not part of the
> package public interfase.

Yes, I would say that falls under the "important not to change the
external usage" exception I gave.



Carl Banks