Hi Ryan,
Thanks for your question.
What's the advantage of making them private in the first place? You can
always get around it with `send`. Unless dynamically looking up methods, it
really just serves as a guideline to developers that "hey, this is method
private to this class." So just using your naming convention should
suffice, without need to alter functionality.
Hi Robert,
The API reference should be the documentation.
If you look at proper documented ruby code like Rails code base you will
see that your option of putting public methods all together makes no
difference for that purpose.
<<<<
Well, we weren't talking about documentation, but that's an interesting
point. Are you saying that the order of the methods in the class doesn't
matter, because the rdoc/yard web pages ignore them? You might be right --
but we both still prefer to order methods in the class in a particular way,
don't we?
I find it interesting how many elaborate ordering schemes for methods
seem to be around. I usually only have a block of public methods at
the top and private methods at the bottom. Other than that I don't
employ a particular scheme. Put differently: the need for such a
scheme could be an indication that classes have too many methods on
average. 
Kind regards
robert
···
On Fri, 13 Jan 2017 at 19:47, Ryan Buckley <duhryguy@gmail.com> wrote:
On Fri, Jan 13, 2017 at 9:24 AM, Daniel Ferreira <subtileos@gmail.com> wrote:
On Fri, 13 Jan 2017 at 17:18, Robert Klemme <shortcutter@googlemail.com> wrote:
On Fri, Jan 13, 2017 at 4:43 PM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
When we start to implement a public method and extend the class with it
then we need to go down and right the private method.
It is time consuming.
Also it is harder to refactor.
If you have public and private method together you pick them up and create
the new class without any problem. Just by delegating the public method
into the new class object.
There are other things I can point out as advantages.
Thanks,
Daniel Ferreira (Subtileos)
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I believe the class public interface (API) should be only limited to the
methods strictly necessary to deliver the functionality.
Only these methods should be object of (unit/integration) tests and all
public methods should be object of those tests.
These are the simple rules.
Then I have more.
All public methods should have a clear documentation for their use cases.
Each classe should be designed with the API in mind and with the goal of
keeping it as small as possible.
No problem in adding more private methods (normalisation).
Strictly forbidden to add more public methods without prior discussion or
consideration during class design.
TDD is where all starts but documentation should be written during
development.
In a PR if documentation doesn't explain the architecture and usability
gets rejected.
Coding with the mind in future developers that will be on board.
New developers should have no problems in understanding the architecture
and design patterns in place.
Maintainable code as the first concern.
I've seen enough spaghetti code in my life.
If you can't right the tests and document them then you don't know what are
you coding for. That is an assumption but my rule.
Plenty of more thoughts about it.
It all comes from experience.
Thanks,
Daniel