Breaking a Circular Dependency

I once faced a problem while adding support for a new integrator API alongside a legacy integration. The legacy integrator module was monolithic, compiled as a single static library together with the forms that used it, and it contained the most important and complex component: a document generator that would have taken about a month to reimplement.

The circular dependency

The system was split into two parts: the main application, and a static library containing the legacy integrator and the forms that used it, linked together to produce the final application. Adding the new integrator as a separate static library would make it a third module, but the new integrator needed the generator from the legacy library, while the forms in that library needed the new integrator. Each module would have to include the other, a circular dependency.

Asking what the dependency really was

I took a step back and asked what the new module actually needed. The answer was just the generator method, not the whole library. So instead of including the library, the new integrator accepted the generator as a callback, passed in as a parameter. The new module no longer depended on the library, the dependency flowed in one direction only, and a month of reimplementation was avoided.

The lesson

Before reaching for a big refactor, look at what the dependency really is. Sometimes a module doesn't need another module, only one of its behaviors. Passing that behavior in as a callback, a small-scale form of dependency inversion, can turn a tangled circular dependency into a clean, one-directional one.

Conclusion

A month of planned rework was avoided by isolating the one function the new module actually needed and passing it in as a callback, instead of linking against the whole legacy library.