The hard part of refactoring
Last updated at 5:10 pm UTC on 16 January 2006
The "bad" dependencies (cf. How to modularize a piece of the base image) are created by methods that reside in modules that shouldn't depend on you. These are the methods that will have to be refactored in various ways to untangle the bad dependencies. Often these dependencies are circular and involve more than two modules. This is the hard part of the work. Note that this should be done before running defineClassExtensionsOutside:, or the delta modules will include type 3 deps as well.
There is no simple formula for this task, you will have to figure this out from case to case.
Often you have to involve more than two modules in you reshuffling.
One idea is that you can create a new module where the code can be moved. E.g. example methods often create bad dependencies because they use a lot of different classes to demonstrate how they work. However, these example methods are not crucial to making the module work, so you can move them and thereby remove these bad dependencies. You can in this way create a "Demo" (sub)module where the example code can be moved.
A proposed modular image architecture suggest the principles for restructuring the code in this way, into e.g. "Demo" modules and others.
