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".
For me private is an admission that I don't really think this object should be responsible for this logic, but I'm not sure where else to put it. I do think it is helpful to signal that to other developers, and private fits the bill imo. If somebody on my team wants to make use of that logic, it's a cue that we should have a discussion about where it belongs. Until then it saves me from going too deep into yak shaving on a design.
If you are finding a lot of useful logic locked up in private methods, that to me is an indication of poor design, which is a completely different discussion than public vs. private.