The problem I generally have with OO is that most people don't know it and then they get frustrated (and rightly so). This is because it's not being taught very well and I certainly had painful experiences with it when I started. That being said, I can't say I disagree with your post, but I can't agree with it, either, because I don't understand what you're trying to say. I guess I work better with examples :)

My argument goes like this: expose nothing.

Pretty simple, eh? If the class should be responsible for something, others should not know or care how the class does it. This is even more important if exposing those details allows code outside the class to put an instance (or worse, the class itself) into an invalid state. By pulling logic outside of the class, this risk increases. For example:

my $auth = Authentication::Manager->new( { store => $store } );
if ( $auth->authenticate($username, $password) ) {
    delete_the_data_store($store);
}
else {
    throw_some_exception "invalid credentials";
}
[download]

That if/else is a bug waiting to bite. It only takes one absent-minded programmer to forget an if/else block there and then life becomes pain for everyone.

The authenticate method should probably be throwing its own exception and the calling code, if it cares, should catch it. By not doing this, it's much easier for the calling code to forget to check the return status of that method. Forcing the consumer of a module to write extra code is a recipe for bugs. Here's a somewhat better way:

my $auth = Authentication::Manager->new( { store => $store } );
$auth->authenticate($username, $password);
delete_the_data_store($store);
[download]

Because authenticate throws its own exception, you can't reach the offending code unless you authenticate (i.e., forgetting an if/else block doesn't matter) and the code is easier to read. You can't forget to check the return code (unless you explicitly have a block eval and don't check $@).

So the point I am making is not "shove everything inside of the class". It's "expose nothing until you know you need to expose it". I've found that this has worked very, very well in managing larger code bases.

The problem I generally have with OO is that most people don't know it and then they get frustrated (and rightly so).

My biggest problem with OO, is that there are a bunch of people--like you--that think they know what they are talking about, but don't.

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. Consider, just briefly, whether what you are selling is stone tablet, sermon-on-the-mount material?

Or just your best guess as to "What's best practice"?

Nothing in that post can be dismissed as "the ramblings of BrowserUk". Verbatim quotes back by extensive references to a known, attributed, published author.

Are you sure, really sure, that you know better than he does?

If you are, go argue with him.

If you're not quite so sure of yourself as when you type that diatribe above, then think carefully before responding.

You may think you know who I am, but you only know what I've told you. I have many persona's. At least three here at PM. (And no Tye, checking the IP logs won't help. All my IPs are dynamic and I have ISP accounts in Poland and Russia as well as the UK).

So, whilst I may advocate (strongly), "Examine what is said, not who speaks", sometimes, it is a very revealing exercise to consider ones own experience and knowledge in the light of those with whom one takes issue. (Note: Him, not me).

So the point I am making is not "shove everything inside of the class". It's "expose nothing until you know you need to expose it". I've found that this has worked very, very well in managing larger code bases.

And there you go, making the typical "OO cool-aid drinkers mistake". Read the article. I'll quote, directly this time, a (multiply) published author. An "expert in his field":

Encapsulation is a means, not an end. There's nothing inherently desirable about encapsulation. Encapsulation is useful only because it yields other things in our software that we care about.

The assumption, that encapsulation is king, (along with "inheritance is king", "polymorphism is king") is wrong. In so many ways. Only one of the four tenants is king: "abstraction". This can be defined as

• the process of formulating general concepts by abstracting common properties of instances.

  Which is accurate, if a little pedestrian. There is another definition which is far more important though:

• the act of withdrawing or removing something.

  Whilst what you advocate or aspire to, complicates rather than simplifies, you are, as the saying goes, a part of the problem, rather than part of the solution.

  ---

  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."

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.

Cheers,
Ovid

New address of my CGI Course.

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.

Cheers,
Ovid

New address of my CGI Course.