There's nothing in Hollub's article that doesn't also apply to public member variables. His getX example applies equally to a member variable X. The real point is that providing access to implementation dependent parts of objects is bad and providing it through an accessor doesn't magically make it OK.

In C++, Java, Perl, people rightly add accessors to prevent reliance on direct access to member variable because if all the clients treat something as a member variable then you can't change that without breaking the clients. So instead of public members you end up with private members + set/get methods.

The problem is now that all your members are private - both the really private stuff and the stuff that's intended for public use. This is where confusion begins. The "privacy" of a member variable is now decided by it's accessor and the declarations that goes along with the actual member are redundant. Word then gets around that the "correct" way to program is to make all your member variables private and write accessors for them. Then there are tools which will do this for you but alas there is no longer any way to indicate which members should be private and which public (they're all marked private). Next thing you know, there are public accessors created for all member variables so now everything is effectively public.

Object Pascal (a frustrating language) comes pretty close to getting this right. It allows you to declare things which look like member variables and can be public, private etc but when you read it it calls a getter and when you set it it calls a setter. The client neither knows nor cares what's happening in the background and you get to keep meaningful public/private declarations.

Basically don't expose it if it's not part of the external spec of the object. Some objects are supposed to have "data slots", some aren't. Don't go creating data slots when you shouldn't.

As for testing, test whatever it is useful to test. Forget dogma. If you don't test a private function you lose all the benefits of testing. If you do test it, the worst that can happen is that when you refactor, the test will become irrelevant or wrong. So what? This could also happen to your publised API tests if you decide to change the API.

That said, it might be a good idea to separate the tests. Have one file for the public API and one file to test the inner workings.

In reply to Re: "Accessors break encapsulation"? by fergal
in thread "Accessors break encapsulation"? by tlm

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.