[NotarySojac]

Let me put this question "What are private methods for anyway" into context before you answer. I'm a little perturbed by the way marking methods of a class as 'private' makes them more complicated to test. The only reason I want to use private methods in the first place is because in C# when you mark methods private, the IDE's intellesense hides those methods which improved the coding experience for me as a user of my own code. Now I'm using Aptana which doesn't really have much in the way of code assistance and I'm not sure why else I would want to mark methods as private except to mark the class's 'entrypoints' so I don't forget how the class works. I've just now come up with a workaround for this problem

   private

will from now on be coded as

   #private

Now I can use TDD even when working on classes with many small, logic intensive helper methods instead of using trail and error in irb or booting up a debugger session.

So am I missing out on anything cool with this approach?

[RudiVisser]

Some things should be kept entirely to yourself.

In the class context, this is private, and it does of course have it's applications. I'd say it's perhaps more apparent for properties rather than methods, in that you can hide the internal workings of a class that performs complex calculations or algorithms by making such data completely hidden to the outside world/consumers of the class.

Of course, like everything apply sporadically and only with good reasons. There are many people who will disagree and use them for different reasons entirely, but off the top of my (slightly intoxicated) head this is the best that I can come up with right now.

[Lemur]

Methods are kept private to conceal the inner workings of the program from public accessing. Now what good is that you may ask? Say you have a rather common method, like TALK and a few classes that implement a method like that, Human and Alien. Each of them have radically different ways of defining talk, but if they're both public methods, there's a chance that the program can throw a shoe and flip out if you poorly reference something.

You don't make a safe and show everyone what's inside, it ruins the purpose of the safe.

[NotarySojac]

Quote

...in that you can hide the internal workings of a class that performs complex calculations or algorithms by making such data completely hidden to the outside world/consumers of the class.

Could you elaborate on that? Do you mean you use it as a code obfuscation technique, or for preventing methods from showing up in intellisense-like IDEs? I think in ruby the code is always visible in plain test, even if you've "hidden it from the outside world."

Lemur, on 06 September 2012 - 09:39 PM, said:

Methods are kept private to conceal the inner workings of the program from public accessing. Now what good is that you may ask? Say you have a rather common method, like TALK and a few classes that implement a method like that, Human and Alien. Each of them have radically different ways of defining talk, but if they're both public methods, there's a chance that the program can throw a shoe and flip out if you poorly reference something.

You don't make a safe and show everyone what's inside, it ruins the purpose of the safe.

Ok, that makes a little more sense, making the safe and all that. I still can't work out your example though,

alien = Alien.new
human = Human.new

# As you say, alien and human shouldn't talk
alien.talk human
#=> this shouldn't ever happen

# But if they're marked private, aren't you preventing this situation too?
alien.talk Alien.new 

Also, what's your take on the way it interferes with testing? Do you do TDD when you ruby? I'm just starting to get into it, but I keep running into little hurtles like this one.

This post has been edited by NotarySojac: 06 September 2012 - 10:50 PM

[jon.kiparsky]

I'm not a Ruby developer, but I'm pretty familiar with object-oriented programming, so I'll chime in from that perspective. The purpose of private methods in object-oriented programming generally is to allow an object to encapsulate implementation details and expose only the methods that ought to be exposed.
This allows the person developing and maintaining the library to change (and improve) implementation details of the library without the risk of breaking things for someone who has come to rely on some helper method that they wrote. By limiting access, I make my promises more specific, and therefore more reliable.

This is really a question about OO design, and there's plenty of writing on the subject of access control and encapsulation, so I won't try to go into futher detail here: in general, private methods are just a means to good design.

Quote

Could you elaborate on that? Do you mean you use it as a code obfuscation technique, or for preventing methods from showing up in intellisense-like IDEs? I think in ruby the code is always visible in plain test, even if you've "hidden it from the outside world."

No, it's not for hiding anything from the user. Your commmitment to openness is appealing, but this is about implementation, not visibility. Really, you shouldn't be unit testing the other guy's internals. You might do black-box testing on the library as a whole, but as the consumer of the code, the only thing you have an interest in is knowing that the public methods work as advertised. The internal methods are not your concern - and isn't it nice to know that they're Someone Else's Problem?

[NotarySojac]

Well said, thank you Jon, that makes perfect sense now! In an unrelated project, I've found myself in a position where I've released a small bit of code to the public, and I'm now in an awkward position where I need to change how it functions... if I think in the terms you've outlined here, I see that I have full tweaking rights on all methods I've marked private (and methods I haven't implemented yet) as long as the public ones still work.

One of the idiosyncrasies in ruby is that debuggers are under-developed and actually considered obviated by pure unit/ integration/ acceptance testing (which might sound crazy, but it actually works when you get the hang of it in 90% of the cases I run into and means you never need to debug something twice). It surprises me that when developing unit tests for my own private methods, the interpreter yells at me for testing them. I'll definitely implement the testing workarounds instead of simply commenting the private markings out, given the case you've presented here. Thanks for chiming in!

[Lemur]

RSPEC for testing.

[jon.kiparsky]

NotarySojac, on 07 September 2012 - 12:02 PM, said:

Well said, thank you Jon, that makes perfect sense now! In an unrelated project, I've found myself in a position where I've released a small bit of code to the public, and I'm now in an awkward position where I need to change how it functions... if I think in the terms you've outlined here, I see that I have full tweaking rights on all methods I've marked private (and methods I haven't implemented yet) as long as the public ones still work.

The case you describe is a perfect example of what I'm talking about, I couldn't have put it better myself. Glad I could help to clarify things.