Name that refactoring: 1 - Version 2 14
Here is an update to the first name that refactoring based on feedback. How about this?
Step 0: Method with embedded dependency
Step 1:Extract method to move dependency to another method
Step 2: Subclass and override method with new code that does not have original dependency
So what do you think? Better or worse?
What about using the star in other image? In general, the star could represent the dependency we’re trying to get rid of.

The star confuses me. In general the text helped a lot understanding the graphics. Overall, I think it’s comparable to the previous one.
I have to agree with Markus that the star is a little confusing but once you have the legend, i.e. a worked example, the graphics are superb. I really like the format you’ve come up with. Very subtle but very easy to understand once you know how to interpret them. Bit like Feynman Diagrams for code!
I think the star is confusing because there is no entity that corresponds to it in code: the lines are methods code, the second box is the subclass… The star is a dependency… uhm…
I think we are now spoiled, because we know the first version and know what it should tell. Despite that, it’s definitely an improvement (I notice that methods are now grey boxes, and classes are black boxes :) ). I also like that you use waves instead of lines, to make the point that these are different lines of code.
The star … the intention is good, but maybe there’s a symbol which is understood as an external system. Maybe the problem is, that a star is generally assumed to be something good, while here you want to get rid of it.
I like the star as a fresh symbol with no other prior meaning to consistently refer to a worrying dependency.
However the star has a positive connotation to me, as opposed to the dependency (what about an exclamation mark somewhere?)
On the other hand, the template method pattern is not self-explanatory enough.
too complex
As others, I prefer the “cloud” version. Maybe you could try a “weather” cloud even with some thunder to underline the potential “Chaos” out there. Or a pictogram that can easily identify itself as such.
I liked the cloud better. The star is a sharp, well-defined shape, so I associate it with a single method call or something trivial.
The cloud better expressed that the classes (in example 2) or the method (in example 1) were accessing some ominous dependency, like methods from some OS-provided API.
If you’re representing a dependency, maybe a knot or a chain link would be more obvious iconography?
Since you explained what the star means and gave a caption for each image, it is clear to me.
Perhaps consider something like a flag, and work it into the description. I.e. “We have flagged a dependency that we want to isolate.”
If you are doing this for training purposes, the second is better. Text and basic graphics help. I think the star icon can be improved. The chain or link as mentioned above or another box to continue your existing symbols
I’d replace the star with a red exclamation point (!). It is often used to signify something bad, important or otherwise something to look out for. Difficult dependencies are absolutely something to look out for so I think the analogy would work. Hence showing you are now avoiding the exclamation point aka the bad thing.
I think that it is better to do like this.