

Refactoring code that accesses external services - henrik_w
http://martinfowler.com/articles/refactoring-external-service.html

======
e28eta
I like the goal of the article, I think it does a great job of refactoring a
typical-looking method with too many responsibilities into a reasonably
decomposed system. I also really like Fowler's technique of strict refactoring
augmented with tests.

However, I don't think his articles (like this one) do a very good job of
teaching that technique. While reading, I don't know where the code is headed
(maybe I need to read the end first?), so I don't have a good frame of
reference to understand each intermediate step, or the rationale for choosing
it. He presents a refactoring (complete with link), but doesn't explain what
leads him to choose that refactoring at this particular stage.

On Blooms Taxonomy, I don't feel like this article even gets me to the
Applicative stage, at least for the intermediate refactoring steps.

On a different note, I was surprised that the YoutubeConnection still
contained the fields to retrieve (the 'part' parameter). Once he color coded
the initial state, I expected to see that list of response fields to be
extracted into a parameter. On the other hand, the way the final code is
structured, it would be provided by the VideoService, which doesn't seem right
either.

~~~
lgunsch
Yeah, there is a whole host of things that are left unsaid. He does a lot with
TDD, and other principles like SOLID, refactoring methodology, and testing
patterns that are normally associated with clean code. This topic could easily
be expanded into a whole book for beginners. This is just barely scratching
the surface, probably more like just wiping the dust off.

------
jaredcwhite
These kinds of articles often tend to annoy me because the end-result code
doesn't necessarily look any better, just convoluted for the sake of perceived
modularity/maintain ability. However, I thought this article was excellent,
and Martin did a bang-up job of illustrating the kinds of decisions
experienced OO programmers make when they're writing or refactoring code. I
also thought Martin's suggestion to use pattern names in class names was
interesting. I'm not sure how I feel about that -- maybe for
beginner/intermediate programmers it's a good habit to have.

~~~
vinceguidry
Personally, when I'm refactoring code, it'll go through a phase where the
classes are named for the patterns they're using, but eventually, they all get
single names and get put under modules that usually only hold other classes
with that pattern. Like, I'll have a "Gateways" module for the YouTubeGateway
to go into, and then it'll just get renamed "Gateways::Youtube".

I used to do "Youtube::Gateway", but I find that grouping by functionality
allows me to DRY up code a lot better and winds up being cleaner. Actually,
with Gateways, I maintain an internal gem that I use just to manage them. I
got tired of reimplementing FTP gateways every single time I needed one. So I
just include the gem, it's called Orchestra, and just call
Orchestra::Server[server_name].ftp_get(path). The gem has all the URIs to
connect to, all the code managed with its own DSL.

------
mazer_r
Learned a lot, hopefully Martin's curiosity leads him to follow through with
the same codebase refactored in a functional style.

