Refactoring code that accesses external services
martinfowler.com
Refactoring code that accesses external services
1–7 of 7 posts
Re: Refactoring code that accesses external services
#2These 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.
Re: Refactoring code that accesses external services
#3I 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.
Re: Refactoring code that accesses external services
#4These 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 patter…
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.
Re: Refactoring code that accesses external services
#5These 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 patter…
It may not look better to you, but I find it works better in the sense it is actually re-usable and understandable.
I have worked in microservice based architectures where the pattern (the one he started with, not the nice result) is repeated thousands of times. You end up with an enormous amount of duplication, and the helper methods, that are designed to be re-useable, are never re-used once. After a few bugfixes in each original method, the code is much more complicated then it needed to be. If it was made modular as he has done, it would still be a rather simple.
Re: Refactoring code that accesses external services
#6I 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 r…
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.
Re: Refactoring code that accesses external services
#7Learned a lot, hopefully Martin's curiosity leads him to follow through with the same codebase refactored in a functional style.