I've read what he's written and his primary thrust is is that syntactic inconsistencies are unavoidable because anything more than a non-trivial use of the class requires them. Since he argues(1), that classes should be both complete and minimal -- needs that are sometimes in conflict -- he asserts that it's better to embrace that up front to accept the minimalism, other wise you have an explosion of methods which can make a class harder to maintain and wind up providing a bunch of useless features that people don't really need (his "nap" function was an excellent example).

Frankly, I agree with most of what he wrote, but avoiding the issues he describes without resorting to non-member, non-friend functions is often very easy -- but you don't want to hear it since, as you were quick to point out, he's an expert and I'm not. Thanks for making that distinction clear.

Update: I should also point out that what he's (the author BrowserUK points to) discussing involves a very long-standing issue with OO design that is extremely well-known, but it's only in the past few years that newer techniques for resolving it have been widely explored. The problem, basically, is that you can't have a class anticipate everything as this violates the need for minimalism and you're going to get it wrong anyway. The author presents one technique for resolving this issue, using something called 'non-member, non-friend functions'. There are, of course, quite a number of other ways to address this. I can think of at least six different techniques for resolving this issue. However, though the author correctly identifies a significant problem, stating that his is "the one true way" out of quite a number of different possibilities seems a bit limiting.

1: His "complete but minimal" argument is correct, in my opinion, and there are strong echoes of a famous paper which addresses this, but since I'm not an expert, I'm not entitled to an opinion here. Ironically, my concrete example is completely unrelated to the issues he pointed out, but somehow that appears to have been lost in the shuffle.

Oh, and I forgot to point out the incredible irony of your post: you take me to task for disagreeing with an article that you didn't understand. You wrote:

Re-read my post to which you responded. Follow the links. Re-evaluate your knowledge and experience in the light of the credentials of the author I quoted.

And later you wrote:

The assumption, that encapsulation is king ... is wrong. In so many ways.

You repeatedly argued that I didn't know what I was talking about, but you apparently didn't understand the article you linked to. Just look at the title:

How Non-Member Functions Improve Encapsulation
Scott Meyers
When it comes to encapsulation, sometimes less is more.

When you read closer what he writes, his "less is more" isn't referring to less encapsulation being better. He's arguing that minimal classes give you an opportunity for better encapsulation. He's arguing that "encapsulation is king" and I agree with him even though you have stated that this argument is wrong. What I don't agree with is the assertion that his "one solution" (out of at least six that I previously alluded to) is the only (or best) solution. Your "encapsulation is king ... is wrong" completely misses the point of what the author was arguing for.

Go back and reread what he wrote. Carefully. Go back and reread what I wrote and see how my concrete example does not, in any way shape or form, conflict with what he wrote.

you take me to task for disagreeing with an article that you didn't understand.

Of course I understood it. Else why would I have made such efforts to emphasis the following (re-quoted with my original emphasis intact):

If, on the other hand, that function can be implemented as a non-member, non-friend, "free" function (sub) it won't have to change if the data format changes, so doing so increases encapsulation.

No one, neither he not I, are arguing that encapsulation isn't important. It's all about how you achieve it. My point was and is clear. It is not necessary, or desirable, to stuff everything inside the class in order to achieve encapsulation.

His point was that encapsulation can be maintained, and even enhanced, by keeping stuff out of the class. Contrast that approach with your "My argument goes like this: expose nothing" approach?

You also say: He's arguing that "encapsulation is king" and I agree with him ..., but I think we must have read different articles.

There are four tenants of OO, and if any of them are king, it has to be abstraction. The trick to effective use of OO (remember the key word in the titles of his series of books?), is to balance those four tenants.

• Inheritance is a useful way of achieving code re-use (DRY), if used correctly.

  But it is well documented that over-use of inheritance leads to a big ball of OO spaghetti (to mix a few metaphors).

• Polymorphism is another useful mechanism for achieving code re-use, when used correctly.

  But using it incorrectly leads to dichotomies that are unresolvable.

  Eg. Building a Point3D class on top of a Point2D class doesn't work, because a 3D-point is not a specialisation of a 2D-point. Any given 2D point will map to an infinite number of 3D-points from any given observers point of view. And that same 2D-point can be mapped to any single 3D-point, from an infinite number of planes of observation. However, a 2D-point can always be derived from a 3D-point successfully.

• Encapsulation can yield benefits in reduced maintenance.

  But they nearly always come with an up-front cost in increased development and complexity. Balancing the needs of the (foreseeable) future against the costs of knowable now, is the trickiest decision every architect has to make.

  Done right, encapsulation minimises the costs of change by containing them, thus decreasing coupling. Done wrong--eg. stuffing everything into one big class--it increases coupling, increases the length of dependency chains, and so increases the costs of change.

  The target of encapsulation, its raison d'etre, is to simplify maintenance. Not to hide everything from everyone.

• Abstraction yields benefits by simplification.

  Files and folders (or directories) are simpler concepts to think about and use than i-nodes, free-space chains and disk-blocks. Arrays are simpler to program than pointers and index register manipulations. CGI forms are easier to use and program than the query strings they hide. Pull-down menus, check-boxes and dialogs are easier to navigate and get right than endless streams of scrolling man pages and huge long strings of nearly meaningless option strings (What do you think the option is to disable spurious warnings of uncheckable memory bounds?).

  But even an abstraction comes with a cost. Simplicity for the user is traded against complexity for the implementor. Again, a balance must be sought.

  But the other three tenants serve only to service the needs of the abstraction. Once sight of that fact is lost, and they start to becomes ends in their own right, the very purpose of OO (simplification through abstraction) is lost also. Thence comes complexity for only the sake of dogma.

There's a long, wordy, difficult and sometimes very repetitive, but oh so insightful document, Object Orientation Redefined I highly commend to you. It's a difficult but very well worth while read.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Then I clearly misunderstood you when you said that "encapsulation is king ... is wrong" and I apologize for that. It sounded to me like you were disagreeing with the idea of encapsulation rather than placing it in context. However, I would humbly suggest that such a subtle point is easily lost when you start out by being confrontational. (Though I'm as just as guilty of the negative comments as I can get riled up when I'm poked)

And you still haven't pointed out how my response to the OP was at odds with the first article. I made an example out a common OO mistake of how not encapsulating something (and thus failing to abstract it) could lead to serious bugs. This is a well-known failure mode by having poorly distributed responsibilities. In regards to the first link you had posted: I was writing about poorly distributed responsibilities -- a common problem I would like to solve -- and the author was writing about achieving minimal classes -- a common problem he would like to solve. These ideas are not contradictory.

Cheers,
Ovid

New address of my CGI Course.