Update: You wrote: With respect to confrontational. I attempted to paraphrase the opening line of your response to me: The problem I generally have with OO is that most people don't know it and then they get frustrated .... This is because it's not being taught very well .....

I should have made it more clear that I was not referring to you when I said "most people know [00]". That's one of the problems with forums like this: it's so easy to for misunderstandings like this to crop up :(

If you can see another way of interpreting those words and snippets, then I'll apologise for having misunderstood you.

When I said that my example does not conflict with Scott Meyers, I was specifically referring to my example to you: the one with ensuring that the authentication object is specifically responsible for throwing an exception to ensure that one cannot forget throwing that exception. Thus, the bits you quote and the bits I was referring to are not the same. Sorry for the confusion.

As for my original "paper" example, I also explicitly pointed out that I had deliberately made things private but that they may need to be made public later. When I'm first building a class, just exposing everything with little regard for what I'm exposing offers two distinct problems:

• Once exposed, I cannot easily revisit the interface (I've made a contract)
• If I expose something that's tightly coupled to something else in my class, I could make it easy to leave the class in an inconsistent state. This should never happen.

I've some code on the CPAN which I would desperately love to change the interface to, but since it's exposed, I now have a contract and shipping new code would break that contract.

Inconsistent state is more insidious. Consider this (contrived but not unusual) example:

my $person = Person->new( fname => 'Bob', lname => 'Smith' );
$person->birthmonth('january');
$person->birthday(13);
print $person->age;  # boom!
[download]

That's the sort of "exposing the gory details" which I want to avoid and I find that when I'm creating a class, there's an excellent chance that I won't know up front what bits to safely expose. If I'm creating a person object, there's a chance that I'll need to know their age and the above code will break terribly since I don't know the year.

Some might argue to just use DateTime objects in this example, but since the 'month' and 'day' are not required, calculating drinking age could easily be off by up to a year. Severe legal consequences there.

Of course, the core of the problem above, aside from exposing things which should not be exposed, is that this code is loosely written in a procedural style. So my argument would be to not expose methods for setting the month and day until and unless you know you really, really need them (and there's a good chance you won't). By forcing the programmer to not expose things until they understand what and why, they minimize the chance for leaving an object in an inconsistent state and thus breaking code unexpectedly. This also has the side effect of promoting a "minimal" class by not accidentally building in functionality that the user doesn't really need -- something that Scott Meyers certainly seems to approve of.