Composed Method: The idea of, rather than having a super long/complex method, you break the functionality up into lots of little methods that are, like, 1-5 lines. Folks general construe that these methods should be private.
Method Object: For a method that would normally take a huge number of arguments or has a lot of local variables that make it hard to do Composed Method, you make an object, store the variables as state and then compose your shit in there. And the original method just delegates over to the new object.
The reason I asked is that it seems like what people generally construe as "should be private" in Composed Method could reasonably be expected to be public on your Method Object. That, anyway, is what came to mind with the phrase "public on another object".
@gilesbowkett Interesting. I agree with the reasoning, but not the conclusion. It might simply require a bit of adjustment on my side so I'll think on it. Currently, my feeling is that relegating the distinction to comments is…wasteful? Unnecessary repetition? In that in Ruby we've a good mechanism in place, with all the benefits (suggestion to not rely on the method and avoidance of accidentally doing so) but none of the drawbacks (you can use the method without much hassle – and get additional documentation from the #send – if you want to, unlike many other languages). TomDoc should also be able to pick up the method visibility automatically, for your documentation.