3 ms·

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 modula

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 12y ago
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.
lgunsch 12y ago
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.

vinceguidry 12y ago

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.

lgunsch 12y ago

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.