I've got some legacy code (both in the sense of code that has no tests, like the definition given in Working Effectively with Legacy Code, and of relatively old code) that I have to extend. There is this one class in particular, which is extensively used through the 'simple' expedient of accessing its member variables directly and using said member's methods (sometimes chained to a depth of 3 classes). That makes it a bit of a nightmare to work with, much to my displeasure.So I'm trying to get that class under tests, and get it to the point where I have a usable interface to access it. However I'm not seeing a clear path between the current state and the end result.After giving it some thought, my current plan is to first wrap all of the uses of members (up to the necessary depth) in the class, which will unfortunately turn it into a bit of a god class. Once every access is done through a proper set of functions, I hope to get the whole assembly of the class hooked into the test framework. After that I hope to be able to start extracting the different interfaces or classes hiding in the mess that will have been produced by the wrapping step.Does that sound like a sensible approach? Is there another approach that would work out better in a case like this?
Refactoring a class which exposes way too much of its internals
refactoring