This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/live-refactoring-with-joe
Thanks for the episode!
I’m not sure if it’s easily fixable, but the video intro has a small typo (“Reafactoring”)
BTW, the site sourcemaking.com linked to in the show notes is built from stolen content (see https://twitter.com/martinfowler/status/424176152090271744).
The private class technique by @jferris stood out to me. However, playing around with it some it seems that the
Payload class would still be publicly accessible. For example:
> class Foo * private * * class Bar * end * end => nil > Foo::Bar.new => #<Foo::Bar:0x007f987a5a62b0>
private_constant keeps the class private.
> class Foo * class Bar * end * * private_constant :Bar * end => Foo < Object 2.2.4 (main):0 > Foo::Bar.new => NameError: private constant Foo::Bar referenced
I know this wasn’t the main point of this weekly iteration, but I was curious if doing it the way in the video had any benefits. It doesn’t appear to keep the class private. Perhaps it worked some point? I was using ruby 2.3 so maybe it changed recently?
@DavidVII thanks for calling that out!
I tend to put “private” classes at the bottom, below the
private keyword. This isn’t because it makes them inaccessible, but because I try to put high-level details at the top of each file, and place internal/implementation code towards the bottom. This way, the file starts out as an abstract declaration of what’s going to happen, and the details are explained in depth as you continue into the file.
I frequently forget that these classes are still public, but I avoid referencing these internal classes anyway out of habit. I’ve started using
private_constant in newer code to prevent accidental misuse, but the habit isn’t fully formed yet.
@jferris Thanks for clarifying