If stuffing everything inside your objects works for you, then go for it.

But there is a point of view, most clearly expounded by a certain author of several very well respected books on C++ that strongly advocates not sticking everything inside your class.

A simple quote: "If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions."

A "non-friend non-member function" is also called a "free function". In Perl terms: a good old-fashioned sub rather than a method. The gist of the argument is that the only measure of encapsulation is the amount of code (number of functions/methods) that needs to change if the data format changes. Any function implemented as a method will likely need to change if the data format changes.

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

Don't be blinded by OO-dogma. To paraphrase and widen a quote from the same article. OO is a means not an end. OO is only useful because it yields other things that we care about. The greatest benefit OO can yield, indeed the greatest benefit any programming technique or methodology can yield, is simplicity. Whilst it does so, it is beneficial. As soon as it starts creating complexity that can be avoided--lines of code that can be avoided--it ceases to be beneficial.

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.

Cheers,
Ovid

New address of my CGI Course.

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