Static to non-static - Organization

I'm working on a project, written by another group, that relies heavily on a few static objects. As a result it makes the adaptability of the project pretty...well, static. For my project I want to reorganize the code to allow multiple instances rather than relying on a single static one so I can customize each instance and its behavior.

It sounds a bit easy, but I hit a problem because so much of the code refers to these static objects. In fact, many of the functions go several methods and objects deep. Imagine the simplistic example where I call method A in the static object A, and it creates object B which creates object C which creates object D, and so on. And all of these created object refer back to A in a static way ~X( . The first way that comes to mind to make this change is to pass a reference of A down the line, but is there possibly an easier way to go about it? Any and all help is appreciated....if this even makes sense

I'm sorry no one has been able to answer you on this one copeg. I would give it a shot but it sounds to me that I would need to spend some time getting to know the system at hand to be able to help you out with a solution.

// Json

Thanks Json. I know its not a trivial question, I was just wondering if there was a simple sort of design pattern that I was missing, which evidently there probably isn't. Changing the code turned out to be easier than I thought though, but all the dependencies really effects the reusability of the code.

Glad to hear you worked it out. Sometimes refactoring is a lot easier than you think it will be :)

// Json

You might find that using a framework like Spring can help with the dependency problems - at my workplace, we've found we can easily add some Spring dependency injection to nasty legacy code, making refactoring much simpler, and it also means there's a lot less passing objects deep into method chains.

The key to this (and also manual refactoring of the kind you are doing) is to make sure that you only ever pass interfaces as dependencies. The discipline of rethinking everything in terms of interfaces often points up design problems that can be fixed or worked around, and once all object parameters are interfaces, the application becomes a lot more flexible.

To do this kind of refactoring, you do need a good IDE - we use IntelliJ IDEA, but the free ones (e.g. Eclipse) are pretty good on this.

Quote:

---

Originally Posted by dlorde

The key to this (and also manual refactoring of the kind you are doing) is to make sure that you only ever pass interfaces as dependencies. The discipline of rethinking everything in terms of interfaces often points up design problems that can be fixed or worked around, and once all object parameters are interfaces, the application becomes a lot more flexible.

---

Thanks dlorde for your input. That is exactly how I did it, using interfaces rather than setting things in stone with objects. In the end it still has dependencies, but things have better adaptability relative to all the object passing.