Public vs. Private debate

[peewee_RotA]

Curious of the opinions of people here based on the wide variety of programming languages. What do you think of the statement: "There should be no private members."

I read an interesting article about it a few months back and have been chewing on it for a while. The main argument is that private methods aren't testable, so just never let them be private.

[QwazyWabbit]

I guess that depends on how much you trust the class you are using or whether you have the sources or not. The statement that private members are not testable is a fallacy. They certainly ARE testable if you want to go to the effort of testing the class as a black box. If you have the sources, you can white-box them.

A class is a contract between the user program and the class, the class promises to deliver the proper functioning of the class if the user confines itself to using the public interface of the class. "Testing" the module is then very easy via the public interface and the boundaries and corner cases of the class are easily delineated and tested. Debugging the class is the job of the class designer and the implementation details of the class are the designer's responsibility.

The whole point of private members is data/implementation hiding and encapsulation and namespace confinement. If everything is public then what is the point?

[peewee_RotA]

I guess that depends on how much you trust the class you are using or whether you have the sources or not. The statement that private members are not testable is a fallacy. They certainly ARE testable if you want to go to the effort of testing the class as a black box. If you have the sources, you can white-box them.

I think that the understanding of "testing" in this context is unit testing in a test driven design approach.

The whole point of private members is data/implementation hiding and encapsulation and namespace confinement. If everything is public then what is the point?

Personally I think the whole debate is pointless. There shouldn't be only public or only private (it'd be funny to see someone try that). They are both tools to be used when appropriate. It's like throwing away your hammer because you think screws are better.


I find it funny when the C# blogosphere acts like a bunch of know-it-alls and tell the world how it should be (That's my job). Eventually they'll abstract themselves into a new plane of existence. 

[yahoo]

the word debate acts like a beacon for Tubby but unfortunately this is about programming

[peewee_RotA]

the word debate acts like a beacon for Tubby but unfortunately this is about programming

Tubby should be a private variable.

[QwazyWabbit]

There can't be the condition of all public or all private. A totally private class can't be used (unless every using class is a friend class or something absurd like that) and an all public class is merely a part of the user space and encapsulation is nonexistent. But you are right, the debate is a red herring.

[quadz]

I read an interesting article about it a few months back and have been chewing on it for a while. The main argument is that private methods aren't testable, so just never let them be private.

Generally I test the public interface.

In C++ when I have occasionally felt it was important to access some part of a class's internals, I've defined public accessor methods which are labled as being test-only.  For ex:

  public:
    Foo * test__get_foo ();


...or whatever.


By contrast, in Ruby, while public/protected/private methods are supported, there are numerous ways to obtain access to a class's internals if you really want to.  (As the creator of Ruby once put it, "Ruby trust you to give you sharp knives...")

So again, while I generally test just a class' public API, on a current project I have a particular test suite which is deliberately accessing a class' internals to force an uncontrolled/unexpected disconnect from the server, to test how various modules recover from the unexpected disconnect.  In that case I'm using instance_eval to execute a code block within the context of the object's own instance, to gain access to internal methods and variables:

  @channels.each {|chan| chan.instance_eval {disconnect_async}}
  @waiter.waitfor {! @channels.any? {|chan| chan.instance_eval{@disconnecting}}}

The method 'disconnect_async' and the instance variable @disconnecting are not part of the public API of that class.

But I try to keep that sort of subterfuge to a minimum.

[peewee_RotA]

Quadz,

Yeah I generally don't do test driven design. I generate my tests after the fact and focus on the public interface first. Then I run sanity type tests anywhere I see a failure point. (database access, passing "object", sketchy eventing, threading concerns, etc.)

I found that intelligently making things virtual and protected keeps my classes easier to maintain in the long run, especially if someone else needs to modify them. But more importantly that lets me make a mock that can give me access to important states that need tested.