Code design

I'm trying to make better structured code, and I have this sort of love hate relationship with OO. Well mostly hate, but it's what I know so it's also what I use.

There's one problem I'm always coming back to and I've yet to solve; Is it ok to use classes to lump code? I know a hardcore old-schooler would scream no, but does it in any way hurt? Say I have this small operation which requires a state but I really don't want to pass it around as data and I shouldn't have more than one of it, do I make it a class or a module or whatever you'd call it?

Somehow it feels better to make it an object, perhaps mostly because again, it's what I'm used to. If the tiny system requires dynamic data, I can blame not deleting the object rather than not shutting down the system. If it's all static, then I still get the feeling that "here it is, right here!", if you know what I mean.. Actually if I make all the member variables and methods static, is there really any difference at all? So if it's not static, is there any difference other than that the state will be lumped as an object on the heap instead?

At the same time it hurts to think that there's an object out there.. which is simply not an object at all.

>>18
HTML+JS.  And I'm not even trolling.

>>19,22
But that requires a huge, bloated VM ("web browser").

>>23
They're gonna have a web browser open while running your product whether you make use of it or not.

>>26
Only if you load both programs inside the same virtual machine.  Otherwise, it's futile.

>>24,25
If you don't count the libraries, then a standard webpage requires far more resources (for example, it's written in HTML, which requires these slow, bloated parsers and complex internal representations), especially if the developer is trying to recreate the desktop application look.
Then there is JavaScript, which is horrendously slow even when JITted.
Also, what if the users don't have a web browser open? What if they have JS disabled? What if they want an actual, separate application?