Agree. But OO code without an OO structure behind is like icing without the cake.

Taking a "spaghetti code" using only global vars and forcing it into an object seems to me a little like sweeping the dust under the carpet: it's a little better, but very little, and perhaps it doesn't worth the effort.

In general the problem is far behind: if you want a good OO code you need a good OO structure that comes from an OO thinking before the project is started (or when it is fully rewritten because you can't understand any more how it works).

Disclaimer: I don't blame the OP for this, for several of my customers have plenty of similar code, much of which written by myself.

I'm certainly not proud of this, but there are situations in which you are requested to do something quick and dirty (quick in my experience meaning "before yesterday") and then to add features and features to these abominations never having the time to refactor or rebuild them.

Taking a "spaghetti code" using only global vars and forcing it into an object seems to me a little like sweeping the dust under the carpet: it's a little better, but very little, and perhaps it doesn't worth the effort.

Agreed, but if done right the "sweeping dust under the carpet" can still help you. Mainly it often allows you to have multiple objects although the original author thought you'd never need that, thus didn't provide the necessary hooks.

For example if Data::Dumper didn't offer an OO interface, it would be virtually impossible to use it with different configurations in different modules. I have no idea how it's implemented, but even if just swept all globals under the carpet of a single object, I'd still appreciate the difference.

(Mind you, I didn't look at the source code. I have no idea how it's implement. This is just a discussion about the interface).