I appreciate that the author calls out "not having private methods" as a possible solution. That's certainly my approach, I feel in general private methods are akin to docker. Yeah they're a useful tool sometimes, but only because of the road strewn with blunders that got us here in the first place.
Didn't unit testing come out of the Smalltalk culture? Smalltalk has no private methods, or public properties. So if there's stuff that's an implementation detail it goes in another object.
Honestly I've never used them of my own volition. So it's not so much that I've faced problems with them, it's just that I've never felt like they solved any problem I had.
I don't even really use "methods" strictly speaking, in general I'll use a dictionary of functions if I want to group functions together semantically, and I'll emit such a dictionary from a closure if for example I need to precompute a lookup table to be used for multiple related calls.
I've had more negative experiences with being denied the ability to do something by overwrought architecture than shooting myself with a footgun someone left in, but importantly I think my approach generally leads to more composability and agility.
> I'll emit such a dictionary from a closure if for example I need to precompute a lookup table to be used for multiple related calls
Isn't this analogous to using private methods, though? I.e. you have some logic to precompute the lookup table that isn't accessible to users of your dictionary of functions? Am I misunderstanding how this works? Or are there benefits of this approach vs. for example having a private method "precomputeLookupTable()" that gets called in a class constructor?
