tweet.md

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".

I think that's basically fair. I think making things private is in general a holdover from Java-era bullshit and really has no place in sane development at all.

I dunno. With SemVer in mind, I feel like having some way to demarcate methods you won't feel bad about deleting, altering horribly or whatever between minor or patch versions is valuable. I'm undecided about whether I think it's best to only ever do TomDoc style comments or that and private as well. It can be easy to miss private sometimes. Still mulling.

Yes, basically that's what I'm saying, anyway.

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.

@supaspoida

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.

this assumes that you're working on a team, and you have time for discussions. I've definitely had this issue come up on solo projects, where I was working against somebody else's solo project. I think I've also had it come up under deadline pressure. I could see an argument for setting guidelines for your team, maybe, but I'm saying avoid public and private as a general guideline, which means it applies whether team or solo, and whether hurried or leisurely. I think overall those keywords are more trouble than they're worth.

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.

well, I definitely disagree on this one. I think it's the same discussion, because I believe that using public or private results in poor design. it inhibits reuse. if you've got code buried somewhere which it turns out lots of people need or want access to in various ways, the faster you find that out, the faster you can refine your design. adding roadblocks which inhibit people from reusing your code in surprising ways inhibits the process of iterative discovery and refinement which eventually results in good design.

also, say you're developing a solo commercial project against somebody else's solo open source project. you come across poor design, and useful content stuffed into private methods is what reveals to you that the design is poor. what do you do then? fork the other programmer's project and fix all the design problems? if forking is considered a method of code reuse, I'd call that suboptimal flexibility.

plus, if they disagree with you because their use case is entirely different, and they've grown attached to the power that public and private give them, they're unlikely to give that power up. no matter how inappropriate or unnecessary power structures are, people hold onto them once they have them. it's as true with programmers as it is with anyone else. you should have seen what Unix sysadmins were like in the 1990s in Silicon Valley. weird little bear gods hoarding power in server caves. wildly dysfunctional.

@benhamill

With SemVer in mind, I feel like having some way to demarcate methods you won't feel bad about deleting, altering horribly or whatever between minor or patch versions is valuable.

I agree with that but TomDoc does the job. Any form of good documentation does the job. Also, again, general guidelines apply to all kinds of projects. The projects where the arguments in favor of public and private are exceptions to the rule. I haven't actually done the research, but my overwhelming suspicion is that the vast majority of projects on GitHub have one committer. It's probably a long tail situation.

When you have a user base in the thousands or more, and you can differentiate between developers and users, and core developers vs. occasional committers, you're dealing with a project people should emulate, on the one hand, but at the same time, you're also dealing with a statistical outlier. What pertains to a gigantic project running some of the biggest sites on the web is not going to apply to every other application out there.

For example Rails. I actually don't think Rails should be using public or private either, but I think making that argument would be a lot more work than making the argument that as a general rule, in the overwhelming majority of projects, you should avoid public and private because they cast opinion in concrete, and you should be very cautious about that kind of thing. opinion should be malleable unless you have a lot of people running code in production. if it's not battle-tested, there's no point holding strong opinions, because nobody has the facts to back those opinions up anyway.

@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.