One thing it captures is the too-often-unclear idea that design patterns are ways to capture best practices, things that people already do. I also like the point at the end about the purpose of design patterns as a communication tool.
I like the story. I'm still having a hard time grasping how the code is better now. But it may be because some of the code was left to the imagination. I'm assuming the reason it's better is because the code that normally passed in "A" or "B" is now passing in the paserFactory. But wouldn't the code that passes that in then have the IF/ELSE? Or are we thinking 2 different pieces of code are doing this?
John said, "I tried that, the user rep. said that it took too long for the code to start parsing that way."
The conceit is that it takes so long to create the Parser that it leaves the user impatiently waiting.
Once you accept that, the rest is pretty standard. First you have two IFs:
These IFs are replaced by a single one:
No further IFs are needed as they have fallen victim to the Replace Conditional with Polymorphism refactoring. In other words there are no further decisions to be made because each concrete factory knows exactly and unambiguously what needs to be done.