Refactoring Pro-Tip:
When I choose a side-by-side approach, I start by finding (or making) the "pivot mount". the place where the final switchover can take place safely.
(So, I re-read that last muse, the one driving this, and I blanched. I didn’t say that very well. The price we pay for extempore musing, I spoze. Still, it’s a worthy topic, so let’s see if I can keep my promise to talk about how, even tho I change terminology from the source.)
Recall the problem: We have some code C that uses code A to do its work. But there’s another way to do that work, B, and for whatever reasons we decide, A is "bad" and B is "good". We want the C code to use B.
Bad typographics:
C -> A (before)
\
> B (after)First, do you see why I speak of pivot? We have C pointing at A, I think of a metal rod as the pointer. I want to twist it to point at B. Sticking with that mechanical notion, the "pivot mount" is the place where C depends on A right now. If we’re going to pivot, we have to start by knowing where that place is, if it’s already there, or making it, if it’s not.
So that’s the first thing. We want it to be the place, that is, singular. If C touches A in a bunch of different ways, that’s our first problem, to "narrow the change".
This is a huge recurring meta-pattern for the master legacy refactorer: she wants the scope of a proposed change as skinny as possible before she starts. It’s simple: changing one thing means holding one thing in your head, changing ten things means holding them all.
Let’s consider the no-brainer first, because the hard ones all violate the no-brainer in ways that give us clues about how to fix them. In the no-brainer, C depends on A through exactly one value, myA, of type A. There are no other dependencies on A. A and B are identical in API.
So? Change the damned type to B, change the passing from being an A to being a B, change the tests to pass B’s, and away we go!
Everyone has done this, though you might not have seen it that way. You did it when, say, in a tiny method, you passed the constant 9 to a library call, and then realized that call takes a double and changed it to pass constant 9.0. Same thing exactly.
So. Complications, then. There are a lot of variants in these complications, and they often show up in combination with each other. Them’s the breaks, kid. Prolly shoulda listened to your mom and become a rodeo clown.
Complication #1: A and B don’t have exactly the same API. It might be a wee bit different, it might be a lot. We have three choices here.
1) Just do it. 2) Refactor A or B’s interface to become more alike. 3) Write an adapter with an API that takes either an A or B and presents the same interface. (That last one is rare: if you can do it, you usually can do 2 directly.)
Complication #2: the A api, including possibly exposed data members and/or return values, uses types or values that the B api doesn’t use.
When this happens, you have to ask yourself the question are you sure that A and B do the same work? The answer could still be possibly yes, but you have to ask it again. If the answer really is yes, then there’s really only a few possibilities.
2A: C is using one simple type A`, the one A uses, but could just as easily use B’, the one B uses. Make C agnostic, or go back to unifying the interfaces so A and B use the same ‘.
2B: C doesn’t really need to do that, it just does it because that’s how it was written. Make it not do that.
Complication #3: This "same job" we’ve been talking about all along is represented tacitly not explicitly in the code. Neither A nor B was built to do that job, it’s just one of the possible things they could be used to do.
Here we hit another huge recurring meta-pattern for the master legacy refactorer: she adores the explicit and abhors the tacit. She wants every relationship in the code to be present in the code, not merely alive in someone’s mind.
The full-on fix this for this: create an exquisite interface that does exactly the one job. Create an impl based on B. Create an impl based on A. Substitute the one impl for the other just like the no-brainer. Delete the A impl, pull up the B impl into that exquisite interface.
So there it is. We need to find the pivot mount, if it already exists. We need to make it, if it doesn’t exist.
The big refactoring, shifting from A to B, is a no-brainer. The hard part is making the pivot mount. That’s a strategy. Next muse, we’ll talk about some specific tactics we can use along the way: converters, adapters, facade, strategy, all our favorites from the GoF book.
These are hard muses for me to write. Normally I’m so much more sure of what I want to say.
Anyway, I hope they fuel some pondering. I hope, generally, you have a nice ponder-y Saturday afternoon!