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.