One module per class, bad idea?

[Gabriel Genellina]

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.


-- 
Gabriel Genellina
Softlab SRL 


	

	
		
__________________________________________________ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas, 
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas